Я полагаю, это зависит от вашей аутентификации, методов авторизации, а также от типа безопасности, которую вы должны учитывать для своих пользователей. Если вы пытаетесь быть RESTful, у вас не может быть сеансов для сохранения состояния (по крайней мере, на стороне сервера). Вы можете, но это не будет RESTful из-за сохранения состояния на сервере, если это имеет значение для вас. Я слышал, что можно спасти состояние на стороне клиента, но из того, что я прочитал, я не уверен, что сообщество думает об определенных реализациях, которые используют этот подход. (Как и куки, я вернусь к этому позже.)
Скажем, у вас есть логин с именем пользователя и паролем. Вы можете хранить эту информацию в своем приложении Backbone, возможно, у вас есть модель AUTH, которая делает это. Каждый раз, когда вы отправляете запрос на сервер, вы отправляете эти данные каждую поездку, и в этот момент сервер аутентифицируется и предоставляет или отклоняет доступ к данным ресурсам. Если вы используете Basic Auth, эта информация будет в заголовке, я думаю. Использование SSL смягчает некоторые основные проблемы безопасности, связанные с отправкой этой информации по проводам, и в оставшейся части обсуждения давайте предположим, что это то, что мы используем.
Другой способ сделать это - использовать зашифрованные файлы cookie, зашифрованные сеансы файлов cookie. Это то, что я делаю с моим текущим приложением. Честно говоря, я не знаю, считается ли это нарушением принципов RESTful или нет. Общая болтовня в Интернете, кажется, состоит из множества «плохих файлов cookie, плохих сессий», когда некоторые говорят: «стань реальным». Использование файлов cookie может привести к угону файлов cookie, если у кого-то будет доступ к компьютеру пользователя, но в зависимости от вашего приложения и требований безопасности это может быть неоправданным вариантом. Это работает для меня, и если это не RESTful, мне нравится называть это RESTLike.
Чтобы закрыть, я просто опишу мои настройки. Было бы неплохо узнать ваши мысли и мнения Стека по этому поводу.
По сути, у меня есть настройка, при которой, когда кто-то переходит на главную страницу, сервер проверяет наличие зашифрованного сеанса cookie. Если сеанс cookie недействителен или отсутствует, он дает пользователю обычную страницу с возможностью входа в систему. Когда они входят в систему, я отправляю эту информацию через POST, поэтому она находится в теле запроса, а не в URI. (Это технически является нарушением концепции глагола REST HTTP, поскольку вы используете POST для сохранения ресурса.) Когда эта информация обрабатывается, проверьте имя пользователя, передайте хеш, созданный уникальной солью, затем сервер создаст зашифрованный файл cookie сеанса и передаст это обратно к пользователю. Теперь каждый раз, когда мой пользователь попадает на маршрут, требующий аутентификации, сервер проверяет куки-файл, чтобы убедиться, что он все еще действителен (ограничение по времени, информация о пользователе и т. Д.) И, если это так, разрешает доступ. Если нет, он уничтожает информацию о куки и отправляет обратно соответствующий код состояния. Магистральное приложение реагирует на это, сбрасывая любое представление и данные, которые не должны быть в руках неаутентифицированного пользователя, и показывает им экран входа в систему.
Надеюсь, это даст вам представление. Это ответ на то, как я это делаю, но если у кого-то есть критика или лучшие идеи, я бы с радостью высказался против них.