#ruby-on-rails #ruby-on-rails-3 #authentication #authorization
#ruby-on-rails #ruby-on-rails-3 #аутентификация #авторизация
Вопрос:
Могу ли я получить несколько советов по дизайну аутентификации / авторизации, пожалуйста?
Это приложение для гаража, которое позволяет клиенту отслеживать состояние своего автомобиля.
Вот мои требования: 1. Мне нужна иерархия из 4 пользователей:
A. Superuser (me)
B. Garage owner.
C. Mechanic.
D. Customer.
Суперпользователь может создавать / редактировать / удалять пользователей A, B, C и D.
Владелец гаража может создавать / редактировать / удалять пользователей C и D.
-
Может быть несколько владельцев гаражей, которым принадлежит одна и та же группа механиков и клиентов.
-
Аутентификация для владельцев гаражей и механиков — это номер учетной записи (который выдает приложение) и пароль.
-
Аутентификация для клиентов основана на их адресе электронной почты и пароле.
-
Единая форма входа для всех типов пользователей.
-
Клиент может видеть только статус своего автомобиля. Механик или владелец гаража имеет доступ ко всем машинам, связанным с гаражом. И суперпользователь имеет доступ ко всем машинам в базе данных.
Моими предпочтительными плагинами для этого были бы authlogic и cancan, но, похоже, я не могу найти элегантный дизайн, который будет представлять права собственности некоторых пользователей другими пользователями, например, что для конкретного владельца гаража все механики или клиенты получают.
Я был бы признателен за любые мысли о наилучшем способе моделирования этого.
Спасибо
Ответ №1:
Я думаю, вам нужна User
модель с garage_id
и role
свойством. Я ожидал бы, что вы могли бы использовать after_save
on User
, чтобы соответствующим образом присвоить login
свойству значение email
or account_number
. Вы могли бы сделать все остальное в классе CanCan Ability
. Очевидно, что суперпользователь будет иметь NULL
garage_id
.
Комментарии:
1. и пользовательская модель также будет иметь car_id? это было бы равно НУЛЮ для всех, кроме клиента?
2. Правильно. Альтернативой было бы иметь
Customer
модель, которая содержала быcar_id
, аUser
customer_id
— a, и которые бы содержали a,,,. Но это косвенное обращение было бы действительно полезно, только если бы у вас были другие материалы, связанные с клиентами, которые вы не хотели бы иметь наUser
.