Я думаю, что предыдущие ответы (предполагающие, что before_filter в контроллере более уместен) немного пропускают сценарий использования OP. Есть все еще преимущества сделать это как условный маршрут / расширенное ограничение. Он не заменяет наличие фильтра «до» в контроллере для предотвращения несанкционированного прямого доступа. Но, например, наличие маршрута redirect_to root_path напрямую, например, профиль пользователя, когда он вошел в систему, или главная страница, если он не зарегистрирован, сохраняет флэш-сообщения, которые в противном случае были бы потеряны при втором перенаправлении в фильтре before. ИМХО более элегантно использовать расширенный подход с ограничениями (при условии, конечно, что сеанс действительно доступен при тестировании пользовательского ограничения). Не говоря уже, в этом случае, почему бы не сохранить дополнительное перенаправление (так как оно включает в себя целую другую транзакцию HTTP (S))?
UPDATE:
Если вы используете Devise, эта статья описывает еще лучший подход. Просто реализовал это сам, и он прекрасно работает, и он чистый.
Кроме того, всегда приветствуются комментарии для объяснения голосов, не только для автора, но и для тех, кто читает ответ и знает, почему это может быть неоправданным ответом.