Es posible especificar dos páginas raíz en Rails (una para usuario anónimo otra para usuario conectado)

Question

Estoy construyendo un producto que tiene páginas estáticas y páginas dinámicas (relacionadas con el producto). Ambas categorías de páginas tienen un ciclo de vida de lanzamiento diferente. El equipo de marketing que trabaja con el diseñador, lanza las páginas estáticas y las páginas de los productos son lanzadas por el equipo de ingeniería.

Las páginas estáticas residen en public/home y son independientes. No necesitan acceso a la infraestructura de Rails aparte de proporcionar enlaces.

En esta configuración, estoy tratando de poner en práctica el siguiente comportamiento:

• Cuando un visitante no-autenticado lanza http://www.xyz.com, el usuario debe tomarse a la página de destino estática.

• Cuando un visitante autenticado inicia http://www.xyz.com, el usuario debe dirigirse a la página de destino del producto (LandingsController, acción de índice).

En mi implementación actual, compruebo si el usuario está autenticado en el mundo de Rails y representa la página estática O la página del producto.

Quiero saber lo siguiente:

1) ¿cómo manejar este tipo de situaciones?

2) ¿Hay alguna manera de evitar ingresar en la pila de Rails para la página de inicio estática?

3) ¿Existe una personalización para el método root_path a devolver diferentes raíz basado en el contexto

Answer 1

Por desgracia, el encaminamiento de Rails sólo puede enrutar las solicitudes a diferentes controladores basados ​​en algo en la solicitud, por lo que la solicitud per datos de sesión fuera de alcance. Su implementación actual es ciertamente la estrategia más común. Estoy adivinando algo como esto:

def index 
    if logged_in? 
    # any logged in logic you need. 
    else 
    render :file => 'public/home', :layout => false 
    end 
end 

La única manera de refactorizar esto para hacer sentir menos "repulsivo" es mover que hacen llamada a un before_filter. Como el filtro tendrá rendered?, su acción no será invocada en absoluto. Por supuesto, también puede elegir redirect_to otra ubicación para solicitudes autenticadas (o no autenticadas) en un filtro anterior, lo que resolvería el problema por completo.

Lo único que podría se basaría en la inexistencia de la cookie de sesión.

1. Escriba un componente de middleware o aplicación de Rack (etc.) que gestione explícitamente la solicitud si no está presente ninguna cookie de sesión. Del mismo modo, podría usar el middleware para volver a escribir la solicitud y luego pasarla a la capa de la aplicación.
2. Utilice una estrategia similar a la # 1, pero hágalo a través de la configuración del servidor web (Apache o nginx), evitando por completo la aplicación Rails.

Pero, definitivamente, es posible que alguien tenga una sesión y aún no inicie sesión (por ejemplo, si fueron a otra página que no manejó de esta manera), o incluso tiene datos de sesión no válidos, por lo que no sería capaz de eliminar realmente el código que tienes ahora.Estos cambios solo servirían para aumentar el rendimiento de las solicitudes sin sesión, pero a menos que esas páginas estén causando un problema significativo (cosa que dudo), así que no recomendaría hacerlo.

Answer 2

1) ¿Cómo maneja estos escenarios?

La respuesta común sería el siguiente:

class LandingsController < ApplicationController 

    before_filter :login_required 

    def index 
    ... 
    end 

    ... 

    private 

    def login_required 
     if not_logged_in? # This methods depends on your authentication strategy 
     send_file "/your/static/path/#{params[:action]}", :type => "application/html charset=utf8;" 
     return false # Halt chain 
     end 
    end 

send_file documentation

Y, dependiendo de la correspondencia entre cada una de sus acciones y sus plantillas, puede más abstracto el método login_required en el ApplicationController, y valide si el archivo existe.

2) ¿Hay una manera de evitar entrar en los rieles de la pila para páginas estáticas

Sí. Tienes que tomar mi palabra, porque yo no lo hice, pero puedes usar un Rack middleware para hacerlo. Here is an example de cómo hacer algo similar, con la excepción de que en lugar de una redirección, usted serviría el archivo estáticamente (simplemente establezca los encabezados y los resultados de File.read como contenido) Esto depende de la biblioteca de autenticación con la que está trabajando, aunque.

3) ¿Existe una personalización para el método root_path a devolver diferentes raíz basado en el contexto

No se puede definir una ruta condicional (es decir, definiendo múltiples rutas en el archivo routes.rb), pero puede anular el método root_url en ApplicationController, suponiendo que está utilizando una ruta con nombre root en las definiciones de ruta. Algo así como

class ApplicationController 

    def root_url(*options) 
    if logged_in? 
     "/return/something/custom" 
    else 
     super(*options) 
    end 
    end 

end 

Esto, sin embargo, suena realmente una mala idea, ya que 1) tiene que introducir a la misma URL, y dejar que el controlador de manejar la petición (sus enlaces deben estar ciego de dónde llevar a usted), y 2) potencialmente puede romper otras cosas que se basan en los métodos root_url y root_path.