Аутентификация пользователей в приложении с одной страницей?

Я разработал прототип приложения для одной страницы, который использует Backbone на передней панели и собирается потреблять из тонкого RESTful API на сервере для его данных.

Исходя из разработки приложений на стороне сервера (php и python), мне действительно понравился новый подход к дизайну с толстой клиентской стороной MVC, но я смущен тем, как лучше всего ограничить приложение аутентифицированными пользователями, которые входят в систему.

Я предпочитаю иметь приложение непосредственно за логином и также хотел бы реализовать другие типы логинов в конечном итоге (openid, fb connect и т.д.) в дополнение к собственному входу сайта. Я не совсем понимаю, как это делается и что мы искали, но не смогли найти информацию, которая дала мне понять.

В общей картине, какова нынешняя передовая практика регистрации пользователей и требуется, чтобы они вошли в систему, чтобы использовать одностраничное приложение?

Как только пользователь вошел в систему, как аутентифицируются запросы api? Могу ли я сохранить сеанс, но как определить этот сеанс в вызовах API или есть ли токен, который я должен передать в каждом вызове API? Любые ответы на это были бы высоко оценены!

Ответ 1

Мы используем аутентификацию на основе файлов cookie django и отдельную страницу для входа и одностраничного приложения. Хорошо работает для нашего случая использования. Мы использовали базовую систему управления сеансом, описанную мной здесь: backbone.js - обработка, если пользователь вошел в систему или нет

Ответ 2

Самый RESTful способ, который я видел, основан на потоке учетных данных клиента OAuth, в основном конечной точке/токена, на которую вы отправляете имя пользователя/пароль, на который возвращается токен доступа для этого сеанса. Каждый запрос ajax после этого добавляет заголовок канала Authorization с токеном. Вы можете хранить токен в глобальной переменной, чтобы просто сохранить его до тех пор, пока страница не будет обновлена ​​/закрыта, используйте локальное хранилище, чтобы пользователи могли войти в систему между сеансами или куки файлы javascript. Если вам не нравится идея токенов, вы можете использовать старый метод cookie, который автоматически отправляется с любым запросом ajax.

Как для facebook/google и т.д. Обычно я следую методу stackoverflow, когда я связываю внешние пользовательские логины с учетной записью. Затем используйте довольно обычный серверный танец на основе oauth (хотя вы можете заменить все запросы на сервер с помощью ajax-запросов с небольшими изменениями, я просто считаю, что это не имеет особого значения, так как вам все равно нужны переадресации между вами и сервером). Я обычно выдаю зашифрованный файл cookie для входа в facebook, который затем конвертирую в токен с помощью аналогичного метода, как описано выше (просто отправьте cookie с запросом вместо имени пользователя/пароля).

Ответ 3

Мы используем Angular.js, а также имеем отдельную страницу для входа. На отдельной странице загружается отдельное одностраничное (и защищенное) приложение, которое вызывает сервер с помощью HTTP-запроса XHR, отправки имени пользователя и пароля. Если сервер аутентифицировал учетные данные, код javascript устанавливает cookie. этот файл cookie может быть прочитан с "другой стороны", что означает незащищенное приложение. В cookie мы вводим только имя пользователя и, конечно, пароль или другую защищенную информацию. то мы можем показать что-то вроде "Не Лиор"? Logout 'в незащищенном приложении.

Единственное замечание - переопределить механизм Angular cookie для установки неопределенного срока действия и, самое главное, корневого пути:

$document[0].cookie = 'username=' + escape($scope.userName) + ";expires=Thu, 01 Jan 2970 00:00:00 GMT; Path=/";