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

Question

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

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

Спасибо

Answer 1

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

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

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

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

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

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

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

Answer 2

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

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

и т.д.

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