Каков хороший способ обойти аутентификацию и / или авторизацию в режиме разработки?

Question

У меня есть несколько действий, которые защищены фильтрами, которые проверяют на logged_in? и admin? и выдают ошибки 401 или 403 соответственно, если тесты не пройдены. Как можно обойти эти фильтры только в режиме разработки , чтобы я мог протестировать свое приложение?

Я не могу пройти процедуру входа в систему, потому что она зависит от инфраструктуры, к которой у меня нет доступа во время разработки.

Я также хотел бы иметь возможность проверить, правильно ли работают 401 и 403, поэтому я не хочу просто полностью отключать все фильтры аутентификации. И я хочу, чтобы он был определен в как можно меньшем количестве мест, чтобы я случайно не позволил миру обойти фильтры в производстве.

Кто-нибудь нашел хороший переопределяющий механизм? Вот некоторые идеи, которые я придумала:

• добавить проверку для params[:logged_in] && RAILS_ENV =~ /dev/ и params[:admin] && RAILS_ENV =~ /dev/ в фильтрах соответственно. Это работает для GET с, но я должен добавить дополнительные скрытые поля ко всем моим формам и моим AJAX-запросам.
• добавить ссылку, доступную только в режиме разработки, которая макетирует логин как обычный пользователь или как администратор. Кажется, это лучший вариант для всех вокруг.

Answer 1

Вы можете добавить некоторый код для функций авторизации, которые возвращают true, если они находятся в разработке.

   def logged_in?
     return true if Rails.env.development?
     ... etc
   end

Answer 2

Вам нужно две вещи, когда вы делаете это:

1. Альтернативный способ передачи аутентификационной информации во время разработки и
2. Способ гарантировать, что это отключено в производстве.

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

Что касается того, что вы делаете, у вас есть много вариантов. Вы можете прочитать информацию из файла, который разработчик редактирует по своему вкусу (YAML - хороший формат для этого, и наличие самого файла может служить переключателем для включения этого. Вы также можете включить авторизованный IP-адрес в этот файл, если вам действительно нужно тестировать с хоста, отличного от localhost). Если у вас есть плагин для браузера, такой как Web Developer для Firefox, установить заголовки очень просто, и это также может быть очень удобно для функциональных тестов через HTTP. Добавление дополнительных параметров к URL-адресу популярно, но я сам не нахожу это удобным.

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

Answer 3

В конфигурации / средах у вас есть сценарии для каждой среды, которые позволяют вам применять параметры среды.

Если эти настройки будут применены достаточно поздно в процессе загрузки Rails, я бы рассмотрел возможность переопределения соответствующих аспектов вашего механизма аутентификации. Это позволяет избежать использования специфичного для разработки кода в вашем производственном приложении, что мне кажется хорошей идеей!

Answer 4

При разработке добавьте в среду сценарий, который имитирует реальную инфраструктуру аутентификации, или переопределите базовую функциональность (например, метод #is_logged_in), чтобы всегда возвращать время, так что в любом случае вы просто меняете часть, которая отличается в разных средах.