Смешивание защищенных пользователей и посетителей на одном сайте

Question

Я подозреваю, что это больше вопрос передового опыта, чем кода.Если у меня есть сайт (RoR3 и Devise), где зарегистрированный пользователь может загружать и создавать документы в базе данных с обычным набором просмотров.Конечно, пользователь должен сначала зарегистрироваться и войти на сайт.Создав документ, они могут захотеть отправить ссылку другому лицу, которое не зарегистрировано на сайте (и не будет).

Итак, я предполагаю, что набор представлений «только для чтения»«если вы хотите, чтобы приглашенный человек мог просмотреть документ, но не может перейти за пределы этого представления, за исключением домашней страницы.Кажется, у Devise нет концепции не зарегистрированного посетителя, которого я вижу, и я не нашел никого, кто бы это сделал.

Спасибо

Answer 1

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

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

В application_controller мы устанавливаемcurrent_user для реального пользователя или просто для объекта, так что он всегда был доступен и крякал как пользователь, особенно включая registered? метод

Сначала мы обернули тонны вещей в наших представлениях с помощью if current_user.registered? повсюду.Но это быстро должно быть беспорядок.Лучшим шаблоном (в тех случаях, когда различия были значительными) было бы создание партиалов, подобных _sidebar и _sidebar_registered, поэтому мы могли бы создать метод, который, учитывая корневое имя частичного, отображал соответствующий в зависимости от состояния пользователя.

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

В общем, были определенные действия контроллерачто только зарегистрированные пользователи могут получить (например, изменить / удалить), мы просто использовали before_filters в контроллере для контроля доступа.По большому счету, все пошло не так.

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

Answer 2

Devise предоставляет вам user_signed_in? метод и метод current_user, чтобы помочь вам с этим. Например, на ваш взгляд, вы можете иметь что-то вроде:

<% if user_signed_in? %>
   <%= current_user.username %>
<% end %>

и т.д.

Если ваши разрешения станут более сложными, я бы порекомендовал использовать гем авторизации, чтобы помочь вам управлять вашими закрытыми разделами. Вот пара примеров: Декларативная авторизация (мой личный фаворит) и CanCan .