Создание рельсов - как обрабатывать сеанс входа в сеанс регистрации

Question

Я должен создать Rails API, который отвечает запросам приложения iPad. Я имею, среди прочего, модель магазина, модель пользователя и модель продукта.

Приложение iPad работает так: после запуска сначала необходимо войти в систему с идентификатором и паролем. Это делается менеджером магазина (вероятно, утром, в начале рабочего дня или даже только один раз, если они никогда не выходят из системы). Это происходит на нескольких iPad. Затем iPad предоставляется клиенту, который в рамках «сеанса» магазина регистрируется как пользователь. Дело в том, что пользователь может входить в систему с одинаковыми учетными данными в разных магазинах, и в зависимости от этого они могут видеть разные продукты в iPad-приложении.

Итак, в рамках сеанса Rails мне нужно сохранить current_user, но также current_shop. Вопрос в том, как это реализовать?

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

Сначала я хотел бы узнать, правильна ли моя общая идея. Кроме того, я хотел бы знать, как вы его реализуете. Я думал использовать Devise для пользователя и ручную проверку подлинности для магазина, но я должен выяснить, как интегрировать оба.

Answer 1

Разрабатывают действительно позволяет использовать любую модель и несколько моделей параллельно. Это позволяет использовать все полезные помощники, такие как current_user и authenticate_shop!.

То, что разрабатывается не из коробки, является механизмом аутентификации API. То, что вы можете (и должны) реализовать yourself

Использование токенов для каждого магазина и учетных записей пользователей выглядит прямолинейно. Вы можете использовать один и тот же базовый механизм (возможно, через HTTP-заголовок).

before_filter :authenticate_xxx_via_token 
def authenticate_xxx_via_token 
    xxx_id = params[:xxx_id] || request.headers["X-XXX-ID"] 
    xxx_token = params[:auth_token] || request.headers["X-XXX-AUTH-TOKEN"] 
    xxx  = xxx_id && Xxx.where(id:xxx_id).first 

    if xxx && Devise.secure_compare(xxx.authentication_token, xxx_token) 
    sign_in xxx, store: false 
    end 
end 

Так сделать это один раз для каждой модели, а затем вы можете защитить ваши контроллеры/действия по authenticate_xxx! и использовать current_xxx.

Наконец, не забудьте добавить SSL к вашему сервису или все это малопригодно.

Answer 2

Я предполагаю, что вы интегрируете приложение, управляемое API, используя программу, будет для вас ограниченным использованием. Вы могли сделать это, но у меня есть чувство, что это вызовет боль, чем это стоит.

Использование Rails built'in has_secure_password - http://api.rubyonrails.org/classes/ActiveModel/SecurePassword/ClassMethods.html

Самый простой поток без сессионных токенов будет идти, как это: имя пользователя

1. менеджер магазина и пароль в приложение IPad (вы можете отправить вызов апи на хост, чтобы проверить, что это нормально), и приложение сохраняет эти значения в своей памяти процесса (а не на диске!)
2. в последующих вызовах API вы повторно отправляете имя пользователя и пароль администратора вместе с именем пользователя и паролем клиента, и вы проверяете оба в before_action вашего базового контроллера

Немного более безопасным решением будет использовать маркер сеанса, который поддерживает несколько Ipads:

1. менеджер магазина вводит свой логин и пароль в приложение Ipad и Ipad приложение посылает магазин аутентификация вызова вы проверить учетные данные и возвращаете SecureRandom.base64 дайджеста и установить Rails.cacheshop_owner/#{digest} ключ к значению shop_id для последующего извлечения, на приложении, которое вы можете поставить дайджест на диске
2. в каждом последующем запросе дайджестотправлен вместе с учетными данными клиента, в before_action проверять кэш для shop_owner/#{digest} и извлечения магазина ID оттуда