#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, чтобы слегка ограничить ресурсы, но хочу использовать область администрирования, которая объединяет представления ресурсов, как вы предложили. Как бы я сделал эти действия (сообщения, пользовательские ресурсы и т. Д.) Доступными для контроллера администратора? Наличие (в основном пустого) контроллера, который наследуется от общедоступных контроллеров, слишком не РАБОТАЕТ? Я просто пытаюсь понять, как текущие действия контроллеров будут доступны для серверной части.