Rails: разграничение пользователей, администраторов и т. Д. С помощью сессий, файлов cookie или пространств имен

Question

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

Новый проект будет иметь пользователей , администраторов и, назовем их, заинтересованных лиц .

Каждый из них, очевидно, люди, и каждый из них должен войти в систему и будет иметь разные «списки». Я знаю, что для этого есть много способов, но я ищу способ "Rails", чтобы использовать как можно больше преимуществ, так называемых "Convention Over Configuration".

• admin обладает сверхспособностями и может видеть и ходить куда угодно
• заинтересованные стороны могут вносить изменения только в свои области сайта
• пользователи (возможно, есть более подходящее название, так как ВСЕ роли в некотором смысле «пользователи») могут только просматривать контент созданный заинтересованными сторонами и при желании прокомментируйте их.

Итак, как с этим справиться ...

Логин: использовать одну форму входа, а затем назначать разные списки? или отправлять пользователей одному логину и админам, другому и тд ...? за и против? Я думаю, что поддерживать один класс User было бы проще, чем разделять их ... но как насчет безопасности?

Маршруты:

• Чтобы избежать вложенных маршрутов (что многие советуют против), я бы хотел, чтобы заинтересованные лица ТОЛЬКО видели свой «кол». Поэтому, когда они входят в систему, им сразу же предоставляется их маленькая область. Интересно, если бы вместо / заинтересованных лиц / заинтересованных лиц / ставок / новых, возможно, я мог бы просто иметь / ставок / новых. Как это обрабатывается? В пользователь? В сессии? Cookie?

• А что насчет админов? Я видел примеры этого броска, перемещенного в его собственное «пространство имен» (я думаю?) , где все задачи администратора начинаются с / admin / ... Это часто встречается? Или есть лучший способ?

• И, наконец, что происходит, когда более высокий бросок (admin или stakeholder) хочет «поделиться» представлением или контроллером, или любым кодом в этом отношении, используемым меньший бросок (user)? если admin имеет свои собственные контроллеры, модели и виды под admin/, тогда уместно ли использовать /stake/new или нам также нужно поддерживать /admin/stake/new?

Извините за путаницу и многословие. Любая помощь, или примеры / документы, будет принята с благодарностью ...

Answer 1

Не существует «стандартного» способа обработки аутентификации и авторизации в ruby ​​на рельсах.Обычно я считаю, что решение на основе драгоценных камней - это лучший способ.Лично я использую Devise и CanCan (размещенный на github, поиск в Google включит его).Посмотрите railscasts.com, как предложено выше, для некоторых замечательных примеров реализации.

К вам вопросы:

• CanCan обрабатывает авторизацию (что разрешено делать пользователю), где Devise (или authlogic) обрабатывает аутентификацию.
• Самым простым способом обработки ролей является добавление логического столбца в пользовательскую таблицу для каждой роли, которую вы хотите определить, поэтому в приведенном выше примере будет логическое значение для администратора, пользователя и заинтересованного лица.Когда вы создаете своего пользователя, вы захотите автоматически установить для пользовательского поля значение true (это можно сделать с помощью фильтра before_save в вашей пользовательской модели).Затем, когда вам нужно предоставить пользователю разрешения, просто установите для этой роли значение true.
• После того, как вы настроите эту настройку, настройте ограничение CanCan на основе этих полей (см. Документацию CanCan или railscasts.com, чтобы узнать, как это сделать)..
• Безопасность: вы упомянули о разделении функций администратора и пользователя и логинов.Это открытая дискуссия для веб-разработчиков, некоторые предпочитают встроенное администрирование (где опции добавления просто отображаются в «общедоступном» представлении), тогда как другие предпочитают совершенно отдельный интерфейс администратора с различными учетными данными.Ответ действительно зависит от потребностей вашего приложения.С точки зрения безопасности, иметь отдельный интерфейс администратора со своими учетными данными и располагаться на отдельном поддомене (например, admin.yoursite.com) более безопасно, поскольку XSS намного сложнее (подробнее @ руководство по безопасности по guides-DOT-RubyOnRails-DOT-ORG)
• RE: домашняя страница заинтересованной стороны. Я не уверен на 100%, является ли stakes вложенным ресурсом или чем-то еще.Если это вложенный ресурс, одним из вариантов может быть использование параметра: shallow routing (см. Здесь: http://ryandaigle.com/articles/2008/9/7/what-s-new-in-edge-rails-shallow-routes)
• Ваш последний пункт самый хитрый, я не совсем понимаю, что вы подразумеваете под "поделиться кодом" спользователь, но ответ, вероятно, состоит в том, чтобы сделать вашу систему разрешений (Admin, Stakeholder, User) более продвинутой и иметь разрешения, связанные с дополнительными действиями, такими как разрешение на создание чего-либо или просмотр чего-либо. Это позволит вам детализировать контроль.количество плагинов для управления ролями (попробуйте Google для них), которые могут предоставить вам это.

Извините, что не публикую больше ссылок, поскольку я, как новый пользователь, не могу опубликовать больше одной, очевидно.

Надеюсь, это поможет.