REST и варианты аутентификации
3 ответа
Я склонен полагать, что детали аутентификации принадлежат заголовка, не URI. Если Вы будете полагаться на маркер, помещаемый в URI, то каждый URI в Вашем приложении должен будет быть закодирован для включения маркера. Это также негативно повлияло бы на кэширование. Ресурсы с маркером, который постоянно, больше изменяется не будут в состоянии кэшироваться. Сопутствующая информация ресурса принадлежит URI, не связанных с приложением данных, таких как учетные данные.
кажется, что необходимо быть нацелены на веб-браузеры как клиент? Раз так Вы могли исследовать использование аутентификация доступа Обзора HTTP или издание клиентов их собственные сертификаты SSL, чтобы однозначно определить и аутентифицировать их. Кроме того, я не думаю, что сеансовые куки являются обязательно плохой вещью. Особенно, имея необходимость иметь дело с браузером. Пока Вы изолируете код обработки cookie и делаете остальную часть приложения не, полагаются на него, Вы были бы в порядке. Ключ является только хранилищем идентификационные данные пользователя на сессии, ничем ином. Не злоупотребляйте серверным состоянием сеанса.
при предназначении для клиентов кроме браузера тогда существует много подходов, которые можно проявить. У меня была удача с использованием Amazon Аутентификация S3 механизм.
Это все очень субъективно, конечно. Чистота и после REST к букве может иногда быть непрактичной. Пока Вы минимизируете и изолируете такое поведение, ядро Вашего приложения может все еще быть УСПОКОИТЕЛЬНЫМ. Я настоятельно рекомендую УСПОКОИТЕЛЬНЫЕ веб-сервисы как большой источник информации о REST и подходов.
Я соглашаюсь с workmad3, если время жизни сессии должно сохраняться, необходимо создать ресурс сессии. Сообщение на том ресурсе с удостоверениями пользователя (или стандартная аутентификация или учетные данные в содержимом тела) возвратит уникальный идентификатор сессии. Удалите на/session/{идентификатор}, выйдет из системы пользователь.
, Если Вы хотите управлять временем истечения сессии. При создании новой сессии (сообщение на ресурсе сессии) сервер установит cookie на ответе (использующий заголовок cookie стандартного набора). Cookie будет содержать время истечения. Строка cookie должна быть зашифрована на сервере, поэтому только сервер может открыть тот cookie. Каждый последовательный запрос к серверу отправит сеансовые куки в заголовке cookie. (это будет сделано автоматически для Вас, если Ваш клиент будет браузером). Сервер должен "возобновить" cookie для каждого запроса, т.е. создать новый cookie с новым временем истечения (расширьте тайм-аут сессии). Не забудьте очищать cookie, когда вызовы пользователя удалят на ресурсе сессии.
, Если Вы хотите, чтобы Ваше приложение было более защищено, можно сохранить клиентский IP в самом cookie, поэтому когда запрос прибывает, сервер может проверить это, это было отправлено от "исходного" клиента. Но помните, что это решение может быть проблематичным, когда прокси включены, потому что сервер мог бы "рассматривать" все запросы как прибывающий от того же клиента.
Остальное аутентификация, которую я видел, рассматривает сессии как ресурс REST для создания, разрушения и т.д. и затем идентификатора сессии, передается туда и сюда. Те, которых я видел, склонны использовать сеансовые куки для этого, поскольку это - единственный способ защитить его действительно. При передаче идентификатора сессии в URL у Вас нет способа реальной аутентификации, это прибыло от корректного клиента.
Аутентификация является хитрой проблемой с REST, хотя, поскольку это требует, чтобы некоторая форма состояния была сохранена вне URL, который посягает на принципы REST URL, являющегося всем, что требуется, чтобы представлять состояние.