Безопасный веб-сервис REST WCF и заголовки - PullRequest
Новая
       1

Безопасный веб-сервис REST WCF и заголовки

1 голос
/ 01 февраля 2012

Я пишу защищенный веб-сервис REST WCF с использованием C #.

Мой код выглядит примерно так: 

public class MyServiceAuthorizationManager : ServiceAuthorizationManager
{
    protected override bool CheckAccessCore(OperationContext operationContext)
    {
        base.CheckAccessCore(operationContext);

        var ctx = WebOperationContext.Current;
        var apikey = ctx.IncomingRequest.Headers[HttpRequestHeader.Authorization];
        var hash = ctx.IncomingRequest.Headers["Hash"];
        var datetime = ctx.IncomingRequest.Headers["DateTime"];
        ...

Я использую заголовки (Authorization, Hash, DateTime) для хранения информациио apikey, текущей дате и URL-адресе хэшированного запроса, в то время как тело запроса содержит только параметры URL и параметров веб-службы.

Пример:

http://127.0.0.1:8081/helloto/daniele

Это правильный путь или яВам нужно передать и получить эти параметры из URL-адреса следующим образом:

http://127.0.0.1:8081/helloto/daniele&apikey=123&datetime=20120101&hash=ddjhgf764653ydhgdhgfjiutu56

есть ли различия между этими двумя методами?

Ответы [ 2 ]

1 голос
/ 02 февраля 2012

Я думаю, что оба метода будут работать для простых случаев.Однако, если вы хотите максимально использовать собственное поведение HTTP, следует использовать подход заголовков, а не параметры запроса URL-адреса.

Это позволит вам (например) использовать коды ответов HTTP для указанияклиенту, что ресурс был постоянно перемещен (код ответа 301), чтобы клиент мог автоматически обновлять ссылки.Если URL-адрес содержал информацию об аутентификации, клиенту не ясно, что два разных URL-адреса на самом деле ссылаются на один и тот же ресурс.В других сценариях перенаправления заголовки включаются автоматически, поэтому вам не нужно беспокоиться о добавлении параметров в URL-адреса перенаправления.

Кроме того, это должно позволить улучшить поведение кэширования на клиентах (если это имеет отношение к вашему сценарию).).

В качестве другого примера, использование заголовков позволит вам аутентифицировать запрос, основываясь только на заголовках, не требуя от клиента отправки тела сообщения.Идея состоит в том, что вы аутентифицируетесь с помощью заголовков, а затем отправляете клиенту ответ HTTP 100 Continue.Клиент не должен отправлять тело сообщения до тех пор, пока не получит 100. Это может быть важной оптимизацией, если вы выполняете POST или PUT с большими телами сообщений.

Существуют и другие примеры, но релевантен ли какой-либо из них.зависит от ваших сценариев и от клиентов, которых вы ожидаете обслуживать.

Таким образом, я бы сказал, что лучше использовать элементы протокола, как они были явно предназначены - это дает вам лучший шанс вести себякак клиент ожидает и должен сделать вашу услугу более доступной, эффективной и пригодной для использования в долгосрочной перспективе.

1 голос
/ 01 февраля 2012

В зависимости от вашей реализации ваши обязательные параметры должны быть переданы в HTTP-заголовках запроса, которых, скорее всего, не будет в строке запроса.

...