#ruby-on-rails #user-controls #authlogic
#ruby-on-rails #пользовательские элементы управления #authlogic
Вопрос:
Я работаю над новым проектом и по какой-то причине решил создать две отдельные пользовательские модели / контроллеры / сеансы с использованием autologic.
У пользователей совершенно разные роли на сайте, но модели в основном одинаковые. Разница заключается только в представлениях.
Теперь я задаюсь вопросом, должен ли я был просто создать одну модель и добавить поле «роль». Затем, после того как они войдут в систему, выясните, какая у них роль, а затем отправьте их на новый контроллер на основе их роли.
Итак, я предполагаю, что мой вопрос в том, есть ли какая-либо причина иметь две пользовательские модели? Существуют ли какие-либо руководства по ролям пользователей с authlogic?
Спасибо!
Ответ №1:
Поскольку Authlogic в основном ориентирован на аутентификацию, добавить разрешения на основе ролей очень просто. Мы сделали это довольно просто, создав единую пользовательскую модель, добавив ролевую модель, а затем создав модель пользовательских ролей, которая связала эти две, что позволило одному пользователю иметь несколько ролей, а также нескольким пользователям иметь одну и ту же роль.
С точки зрения Authlogic, это не имеет значения. Это только позволяет вам узнать, что пользователь аутентифицирован, поэтому любые разрешения, которые вы добавляете поверх этого, являются вашими собственными.
В RoR доступно множество статей о разрешениях на основе ролей, так что просто погуглите, и я уверен, вы найдете несколько, которые соответствуют вашим потребностям.
Однако, судя по тому, что я нашел, простота значительно облегчит вашу жизнь 🙂
Комментарии:
1. Спасибо, этого достаточно, чтобы убедить меня оставить одну модель. Однако существует также двухуровневая иерархия, которая была намного проще с двумя моделями. Одна модель имеет множество других, которые принадлежат первой. Имея одну модель, я нахожу, что мне приходится делать кое-что из funky: through, но через месяц я уверен, что надорвался бы с двумя моделями.
2. Вы могли бы рассмотреть возможность использования наследования одной таблицы, если для вас имеет смысл разделить часть бизнес-логики. Например, у вас может быть пользовательская модель и специальная пользовательская модель, которая наследуется от User. Они обе используют одну и ту же таблицу для данных, но это позволяет вам разделить часть логики. В любом месте вы можете рассматривать специального пользователя как пользователя, чтобы упростить свой код 🙂