2016-08-04 1 views
1

Я создаю приложение для нескольких арендаторов, используя devise и apartment драгоценных камней. Я использую базу данных postgresql. Я создал несколько моделей. Модель «Пользователь» находится в глобальном пространстве имен и используется для аутентификации при помощи gem. Существуют и другие модели (например, Project, Setting и т. Д.), Которые находятся в пространстве имен арендаторов.Рельсы: Многоквартирные дома с драгоценными камнями и драгоценными камнями

Я следовал этому учебнику для создания этого мульти-tenance приложения: https://gorails.com/episodes/multitenancy-with-apartment?autoplay=1

Функция мульти-аренда работает хорошо в том смысле, что, если я войти в два отдельных поддоменов (например, user1.example.com и user2.example.com) из соответствующих учетных записей (например, [email protected] и [email protected]), он отлично работает, и я могу создавать уникальные записи для каждого арендатора.

Теперь проблема заключается в том, что я могу войти в любой поддомен, используя любую электронную почту, и записи арендатора будут показаны на основе субдомена, присутствующего в адресной строке. например Я могу войти в систему с [email protected] по адресу user2.example.com, и она будет успешно протестировать и отобразит записи user2 арендатора.

Мой вопрос заключается в том, как я могу проверить соответствие совпадений текущего пользователя с запрошенным субдоменом (в адресной строке), если он совпадает с ведением проверки подлинности и отображением панели управления admin, а если нет (вход в систему из неправильного субдомена или из TLD) аутентифицировать пользователя, но перенаправить его на панель управления соответствующего субдомена. Как я могу это сделать?

UPDATE # 1:

Я был в состоянии ограничить логин пользователя для их конкретного поддомена с помощью второстепенную конфигурации DEViSE. В файле devise.rb я добавил атрибут :subdomain в список ключей аутентификации, поэтому он также будет проверять правильное значение поддомена вместе с электронной почтой, однако я не уверен, как правильно обеспечить значение поддомена форме входа. Я могу использовать скрытое поле, подобное этому в форме входа <%= f.hidden_field :subdomain, value: request.subdomain %>, но он взломан, так как пользователь может изменить его значение от инспектора браузера.

UPDATE # 2:

Я был в состоянии применить метод доказательства дураком, чтобы ограничить вход пользователя в их конкретной подобласти. Я следовал этому методу: https://github.com/plataformatec/devise/wiki/How-to:-Scope-login-to-subdomain

Теперь моя единственная проблема заключается в том, что пользователь не может войти в систему с TLD (например, example.com), я хочу, чтобы это было возможно, но после входа пользователя пользователя необходимо перенаправить на соответствующий подраздел -область с живым сеансом.

ответ

0

Предположив вы экономите субдомен на User модели, вы можете создать проверку в вашем контроллере вы можете использовать что-то вроде:

if user.subdomain == request.subdomain 
    redirect_to root_url(subdomain: user.subdomain) 
else 
    everything_is_ok 
end 
+0

Я предполагаю, что я должен подключить это условие до фильтра ': authenticate_user', но будучи новичком, я не уверен, как это сделать. Не могли бы вы объяснить это немного. Я также добавил обновление исходного вопроса. –

0

Если вы храните субдомен в таблице пользователей, и если вы проверить это через request.subdomain, то как кто-то может присоединиться к другому арендатору (компании)? Они могут быть включены в более чем одну компанию.

Вот почему я создал 2 средних стола, чтобы справиться с этим.

  • У меня пользователь стол для всех моих пользователей.
  • У меня счет стол для хранения субдоменов с его создателем.
  • И у меня есть account_permissions, чтобы узнать, кто имеет право на то, где.

Так что, когда user1 приходит user2.example.com, я запрашивая к моему Account_permissions, и если у него есть разрешение на user2.example.com, я отпустить ее.

Этот способ кажется ощутимым.

+0

В настоящее время я новичок в рельсах и хочу сделать его простым, поэтому я предположил, что у одного арендатора будет только один пользователь. Тем не менее, структура, которую вы предлагаете, определенно, кажется, очень гибкой. –