Ссылка приглашения Rails Devise не работает

Итак, у меня есть 2 приложения, которые должны работать вместе. У меня есть app1 — приложение, которое будут использовать только наши сотрудники, и app2 — приложение customer_portal, где клиенты могут войти в систему и оплатить свой баланс. Я пытаюсь сделать так, чтобы в app1 мы могли создать учетную запись клиента и связать ее с конкретными клиентами. Этот процесс будет использовать devise_invitable для создания учетной записи для app2 и отправки выбранному клиенту по электронной почте ссылки для настройки своего приложения портала (которое просто принимает приглашение), но по какой-то причине ссылка приглашения не работает и просто перенаправляет на домашнюю страницу. . Таким образом, в основном app2 не может зарегистрировать учетную запись, учетная запись должна быть создана через app1 и отправлена ​​клиенту по электронной почте.

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

PortalUser.invite!({:name => params[:name], :email => params[:email]}, current_user)

Эта ссылка автоматически отправляется по электронной почте http://localhost:3000/portal_users/invitation/accept.20?invitation_token=p7UKK8Z8nKn4busWerpx.

У меня также есть возможность повторно отправить электронное письмо с приглашением на случай, если клиент запросит, но это отправит ту же ссылку по электронной почте.

PortalUser.find(params[:id]).deliver_invitation

Одна вещь, о которой я мог подумать, это то, что ключи шифрования-дешифрования различны для двух разных приложений, поэтому, когда app2 пытается расшифровать токен, он просто выглядит как неправильный токен. Если это так, знаете ли вы, как я могу изменить эти ключи, чтобы они соответствовали? Или, скорее, дайте app1 ключ шифрования app2 и скажите devise использовать этот ключ шифрования для всех приглашений или учетных записей для app2.

Редактировать: Итак, я обнаружил, что могу назначить secret_key в config/initializers/devise.rb, и он будет работать, если оба приложения используют один и тот же ключ. Однако у меня все еще есть вопрос, представляет ли это проблему безопасности?


person MyNameIsntBob    schedule 17.05.2021    source источник


Ответы (1)


представляет ли это проблему безопасности? - В некотором смысле, есть проблема с безопасностью. Например, любой, кто вошел в одно приложение, сможет получить доступ к другому. Похоже, что одно приложение является внутренним или административным приложением, а другое — приложением, ориентированным на потребителя. Вход в один не должен давать доступ к другому.

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

Редактировать:

Вы можете создать токен, который можно использовать для входа.

token = SignInToken.find_by(token: token)
user = token&.user
sign_in(user, scope: :user) if user

Ссылка: Devise Wiki

person B Seven    schedule 18.05.2021
comment
Приложения используют разные таблицы для хранения информации об учетной записи. Учетная запись в одном приложении не может войти в другое приложение. Мне интересно, будет ли у них один и тот же секретный ключ какой-либо проблемой. - person MyNameIsntBob; 19.05.2021
comment
Это зависит от того, что хранится в сеансе. Если он использует идентификатор пользователя, то наличие файла cookie одного приложения даст доступ к другому. Это также зависит от того, какое хранилище сеансов. Звучит как плохая идея, которая создаст больше проблем. - person B Seven; 19.05.2021
comment
Есть ли другой способ заставить его работать, не имея у них одного и того же секретного ключа? - person MyNameIsntBob; 21.05.2021
comment
Я думаю, что может быть способ войти в систему пользователя. Затем вы можете создать одноразовый токен и отправить его пользователю по электронной почте. Это будет та же функциональность, что и приглашение Devise, но с использованием другого токена. Пожалуйста, смотрите редактировать, чтобы опубликовать. - person B Seven; 21.05.2021