Стоит ли использовать для этого гем авторизации или простой метод before_filter? - PullRequest
1 голос
/ 16 июня 2011

У меня есть два типа пользователей: пользователь и редактор. У меня есть модель User с логическим столбцом is_editor, чтобы определить, является ли пользователь редактором.

Давайте предположим. Пользователь Foobar решает зарегистрироваться в качестве редактора. Ему это удается. С сегодняшнего дня он редактор. Однажды Foobar случайно переходит на страницу регистрации редактора (контроллер регистрации, новое действие).

Поскольку Фубар уже является редактором, я должен перенаправить его на страницу своего профиля. Должен ли я использовать для этого гем авторизации (например, Cancan )? Или у меня должен быть простой метод (т.е. before_filter: check_if_user_is_not_an_editor) в контроллере регистраций, который проверяет, является ли пользователь уже редактором, и перенаправляет?

Если я в конечном итоге использую подход Канкан Дело в том, что у меня уже есть следующее, которое проверяет другую авторизацию.

  rescue_from CanCan::AccessDenied do |exception|
    flash[:alert] = exception.message
    redirect_to root_url
  end

Который выдаст сообщение о флеш-предупреждении: You are not authorized и перенаправит на корневой URL. Это не то, что я хочу, потому что вместо этого мне нужно перенаправить в профиль Foobar.

Что вы думаете? Это задача авторизации или просто перенаправление в указанном контроллере? Какой подход является более подходящим?

1 Ответ

1 голос
/ 16 июня 2011

Честно говоря, это кажется довольно незначительным, поэтому, что бы вы ни выбрали, я бы не расстроился из-за вашего подхода. Лично я бы пошел с вашим вторым вариантом (простой редирект). Прежде всего, это кажется проще, что всегда является плюсом. Если вы используете решение для аутентификации, такое как Devise, у вас, вероятно, есть помощник current_user или user_signed_in?, который можно легко использовать в фильтре перед фильтрацией. Во-вторых, меня не особо волнует проблема разрешения.

В каком-то смысле это проблема с разрешениями (я думаю, семантически в любом случае), поскольку ваше приложение определяет поведение, которое «не разрешено». Реально, это не разрешено, но не потому, что у пользователя нет необходимых разрешений. Причина, по которой поведение не разрешено, заключается в том, что ни один пользователь не должен иметь возможность регистрироваться как пользователь того же типа, которого он уже зарегистрировал, то есть нет типов пользователей, которые могли бы делать такие вещи, поэтому в настоящее время Заблокированные в разрешениях пользователя являются спорными. Похоже, что ваша проблема должна быть решена путем определения поведения приложения, а не прав пользователя.

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

...