Ruby on Rails увеличивает количество многоуровневых пользователей с помощью аутентификации и авторизации

#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.

  1. Может быть несколько владельцев гаражей, которым принадлежит одна и та же группа механиков и клиентов.

  2. Аутентификация для владельцев гаражей и механиков — это номер учетной записи (который выдает приложение) и пароль.

  3. Аутентификация для клиентов основана на их адресе электронной почты и пароле.

  4. Единая форма входа для всех типов пользователей.

  5. Клиент может видеть только статус своего автомобиля. Механик или владелец гаража имеет доступ ко всем машинам, связанным с гаражом. И суперпользователь имеет доступ ко всем машинам в базе данных.

Моими предпочтительными плагинами для этого были бы 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 .