Не уверенный существует принятая практика, но здесь теперь, как я сделал бы это:
SELECT
column1,
column2
FROM
table1
WHERE
column3 IN
(
SELECT TOP(1)
column4
FROM
table2
INNER JOIN
table3
ON table2.column1 = table3.column1
)
Если вы сделаете это с помощью ключа, вы измените контракт службы, включив в него поле, в которое будет помещен ключ. Затем проверьте значение в ключе на стороне сервера.
Однако в вашем случае вы можете ограничить, с каких IP-адресов разрешен доступ к службе, с помощью конфигурации сети. Это будет меньше работы, чем изменение подписи ваших служб.
Вы можете легко добавить собственный заголовок сообщения к каждому вызову - на самом деле это довольно легко сделать, и это не «загрязняет» ваш реальный контракт на обслуживание, например, вам не нужно добавлять дополнительные параметры для вызовов службы, чтобы передать это.
См. эти статьи для получения информации о том, как этого добиться:
По сути, вам нужно обернуть ваш вызов службы в OperationContext - это все, не требуется ClientMessageInspector и других уловок: -)
using (OperationContextScope scope = new OperationContextScope(proxy))
{
Guid myToken = Guid.NewGuid();
MessageHeader<Guid> mhg = new MessageHeader<Guid>(myToken);
MessageHeader untyped = mhg.GetUntypedHeader("token", "ns");
OperationContext.Current.OutgoingMessageHeaders.Add(untyped);
proxy.DoOperation(...);
}
, а на стороне сервера вы можете просто проверить IncomingMessageHeaders
коллекция:
Guid myToken = OperationContext.Current.
IncomingMessageHeaders.GetHeader<Guid>("token", "ns");
Marc
Я бы попросил клиента отправить ключ в виде дополнительного заголовка сообщения и создать IDispatchMessageInspector для проверки заголовка и, при необходимости, его отклонения. В этой статье Code Project описывается фильтрация на основе IP-адреса.