Безопасный доступ к аутентифицированному серверу REST через Backbone.js?

Ответ 1

Хорошо, я поговорил с моим коллегой и придумал лучшую идею:

Сделайте простой контроллер на своей стороне клиента (сайте) и назовите его как RESTAPI, он просто будет действовать как обертка на ваш реальный сервер REST.

Когда пользователь входит в ваш сайт, его сеанс создается. Контроллер RESTAPI знает учетные данные для вашего реального сервера REST HTTP Authed, и он обращается к серверу REST от имени магистра.

Пример: если мне нужно выбрать

/сообщения/отправляемые

от REST Server, теперь вместо этого я удалю этот URL-адрес в базовой сети

сайт/restapi/сообщения/отправляемые

Контроллер RESTAPI также сначала проверяет, что запрашивающий пользователь имеет правильную сессию на сайте, и погода, на которую он может получить ресурс, или нет.

Так что не беспокойтесь о небезопасных куках или оставите свой сервер REST в простой JS или используя любой другой неясный метод:)

Ответ 2

HTTP. Обычная проверка подлинности подвержена подслушиванию и атакам "человек-в-середине". Рекомендуется использовать HTTPS.

Однако, если это не опция, вы всегда можете отправить cookie обратно клиенту и ввести имя пользователя/пароль, чтобы он не отображался в JS файле. Идет, не говоря, что пароль должен по крайней мере быть зашифрован/хэширован по соображениям безопасности. Затем брандмауэр будет на стороне сервера, чтобы получить данные аутентификации из файла cookie.

Теперь, если у вас нет контроля над модификацией кода на стороне сервера, вы почти не имеете никакого другого параметра, кроме того, что захотите детали учетных данных в глобальном методе ajaxSend(), который будет отправлять данные имени пользователя/пароля с помощью каждый запрос AJAX. Вы можете просто поместить это в какой-нибудь другой .js файл и затруднить его поиск, но вы в значительной степени ограничены этой формой безопасности. Хотя, куки не делают вашу жизнь более безопасной. (Было бы хорошо, если пароль хэширован/зашифрован).

Другая вещь, которую вы могли бы сделать, - это немного более сложная форма безопасности: пусть сервер отправит nonce обратно с каждым ответом - nonce будет "подписан" сервером, используя секретный ключ сервера, и вы можете использовать чтобы "зашифровать" имя пользователя/пароль на стороне клиента для каждого запроса. Затем ваш сервер должен будет постоянно расшифровывать учетные данные. Это менее склонно к человеку в середине, но все же не является надежным.

HTTPS сохранит вас от каждого из вышеперечисленных, если это вариант для вас.

Надеюсь, что это поможет.

ОБНОВЛЕНИЕ (согласно комментариям): Суть спокойствия - отсутствие состояния на сервере. I.e., нет сеансов! Следовательно, вам нужно отправить учетные данные пользователя с помощью КАЖДОГО запроса, который клиент делает на сервере. Если у вас есть страница входа в систему, очень трудно по-настоящему успокоиться, так как нет "ресурса", называемого login. Однако вот что вы можете сделать:

• Пользователь посещает страницу входа, вводит учетные данные и клики "login"
• Отправьте запрос POST на сервер с этими учетными данными - возможно, чтобы /Login
• Попросите сервер вернуть запрошенный ресурс, для которого требуется проверка подлинности, и установите cookie с действительными учетными данными для использования в следующем запросе
• Каждый последующий запрос будет направлен на соответствующий ресурс по определенному URL-адресу с определенным действием (GET, PUT, POST, DELETE...). Сервер должен проверить данные проверки подлинности из файла cookie и решить, будет ли пользователь аутентифицирован и выполнить дальнейшую авторизацию для предоставления доступа, если это необходимо.

Каждый запрос должен идентифицировать себя, не поддерживая сервер сессию - что дух безгражданства (и спокойствия)

Ответ 3

Если у вас есть доступ к вашему REST-коду на сервере, вы можете переконфигурировать аутентификацию REST. В первый раз для входа в систему вы отправляете имя пользователя/пароль через https, в свою очередь получаете идентификатор сеанса, который может использоваться в последующих запросах, передавая его как cookie.