Пользовательский сервер администрирования Rails 4

#ruby-on-rails #ruby-on-rails-4 #admin

#ruby-on-rails #ruby-on-rails-4 #администратор

Вопрос:

Я хочу создать серверную часть администратора для практического приложения. После прочтения я пришел к общему представлению о том, что делать, но хотел бы получить некоторые разъяснения:

  • Используйте пространство имен для маршрутизации серверной части в example.com/admin …
  • Поместите любые администрируемые ресурсы внутри пространства имен, например, ресурсы: сообщения
  • На этом этапе я дублирую обычные (общедоступные) контроллеры и помещаю их в каталог администратора? (Вместе с грубыми представлениями)
  • Теоретически общедоступным контроллерам нужны только индексирование и отображение действий, верно? Поскольку new / create / update / destroy будет доступен только в admin / controller.

Любые разъяснения или советы приветствуются. Просто пытаюсь разобраться в этом.

Ответ №1:

Я бы рекомендовал не дублировать ваши контроллеры или любую часть вашего приложения, если на то пошло. Это полностью противоречит принципу DRY, который означает «Не повторяйся». Дублированный код становится действительно сложным в обслуживании и тестировании по мере роста вашего приложения.

Вместо этого я бы рекомендовал ограничить доступ к определенным действиям, используя фильтры before. Например, предположим, что вы хотите, чтобы пользователи могли создавать сообщения, читать сообщения и просматривать списки сообщений. В вашем PostsController у вас может быть что-то вроде этого:

 before_action :admin_user?, only: [:edit, :destroy]
 

Примечание: before_action — это просто новое имя для before_filters .

Таким образом, подобные действия index будут выполняться нормально для всех пользователей, но если пользователь вызывает действие уничтожения, контроллер сначала проверяет, является ли пользователь администратором, вызывая admin_user? метод (обычно определенный в ApplicationController). Этот метод может быть простым условным, например, «если пользователь не является администратором, отправьте сообщение об ошибке и перенаправьте их туда, где они были до запроса», а затем используйте его для защиты любого действия или ресурса, который вы хотите. Вы также можете использовать его в представлениях, чтобы показывать кнопки удаления в сообщениях, только если пользователь, например, является администратором.

Это для действий, зависящих от ресурсов. Часто бывает также хорошей идеей иметь раздел сайта, который объединяет просмотры ресурсов и административные действия. Это будет его собственный контроллер / представление (я называю мой AdminController ), и вы можете защитить все действия в нем с помощью описанного выше метода:

 before_action :admin_user?
 

Чтобы сделать ваши ресурсы доступными для AdminController, используя методы, определенные внутри отдельных контроллеров ресурсов, вы можете сделать это в routes.rb:

 namespace :admin do
  resources :users
end
 

Это позволит сделать так, чтобы http://yoursite.com/admin/users/index будет по-прежнему вызывать индексное действие в контроллере пользователей, но это будет происходить в контексте пользователя-администратора (из-за before_action вышеизложенного).

Комментарии:

1. Прямо сейчас я использую before_filters, чтобы слегка ограничить ресурсы, но хочу использовать область администрирования, которая объединяет представления ресурсов, как вы предложили. Как бы я сделал эти действия (сообщения, пользовательские ресурсы и т. Д.) Доступными для контроллера администратора? Наличие (в основном пустого) контроллера, который наследуется от общедоступных контроллеров, слишком не РАБОТАЕТ? Я просто пытаюсь понять, как текущие действия контроллеров будут доступны для серверной части.