Метод REST для доступа к пользовательскому интерфейсу и API

Question

Это вопрос дизайна REST, не относящийся ни к одному языку программирования. Я создаю бэкэнд приложения, доступ к которому осуществляется через REST API. Я хотел бы использовать те же API-интерфейсы как для интерфейса, так и для API-интерфейса. Я пытаюсь найти лучший способ аутентификации пользователей, чтобы я мог повторно использовать те же методы.

Мой текущий мышление аутентификации выглядит следующим образом:

пользователей API

Эти пользователи получают идентификатор GUID пользователя и предварительный общий симметричный ключ. На каждом запросе API они включают в себя дополнительные заголовки или параметры запроса, которые содержат:

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

После получения запроса сервер просматривает заявленный идентификатор GUID, извлекает общий ключ, пытается расшифровать и проверить токен.

UI Пользователи

Эти пользователи будут сделать запрос входа в систему, снабжая человека учетные данные (идентификатор пользователя/пароль). После аутентификации сеанс устанавливается с помощью файлов cookie, а дальнейшие вызовы REST обеспечены на основе этого сеанса.

Проблема

Что это лучший способ, чтобы написать одну REST конечную точку, которая крепит в обоих направлениях: доступ к API и доступ к UI чисто, не слишком много дублирования? Я ищу сделать эквивалент следующего, но, возможно, более аккуратно:

@app.route('/') 
def hello(): 
    user = None 
    if session: 
     user = get_authenticated_user() 
    else: 
     user = process_auth_headers() 
    # Do something with user 

Я ищу код сервера в термосе, но я уверен, что решение будет применяться, как легко любым REST на основе Сервер- боковой каркас.

С нетерпением жду некоторых идей сообщества.

Спасибо.

Answer 1

Мы используем узел для нашего сервера, но я думаю, что метод, который мы используем, довольно распространен. Существуют библиотеки сеансов, которые могут использовать выражения, и могут хорошо использовать любую базу данных для хранения информации о сеансе. Они используют файл cookie с ключом, который выполняет поиск в базе данных при входе клиента. Данные сеанса создаются, когда клиент аутентифицируется, а файл cookie с ключом клиента добавляется в браузер. GUID клиентов хранится в сеансе, он никогда не покидает сервер. Мы используем эту информацию, когда они попадают на сервер, чтобы проверить, вошли ли они в систему, кто они и что они могут делать. Мы использовали оба FB (клиент проверяет FB, а затем отправляет идентификатор FB и токен на сервер, который затем перечитывает и устанавливает сеанс или отклоняет его), или старый классический, электронный адрес и пароль. Это хорошо работает, когда вам приходится масштабироваться на нескольких серверах приложений, поскольку сеанс не зависит от сервера, он работает как для мобильных клиентов, так и для Интернета.