2012-07-20 18 views
6

aplicación My Mojolicious tiene algún tipo de mecanismo de autenticación personalizado, que implemento en una condición de enrutamiento denominado auth_permission:¿Por qué Mojolicious anida mis rutas?

$app->add_condition(auth_permission => sub { 
    return is_user_allowed(...) ? 1 : 0; 
}); 

Así que mis rutas ser algo como esto:

my $r = $app->routes; 

$r->get('/prefs') 
    # no permission necessary here 
    ->to(...); 

$r->get('/objects') 
    ->over(auth_permission => 'view objects') 
    ->to(...); 

$r->get('/objects/delete/:id') 
    ->over(auth_permission => 'delete objects') 
    ->to(...); 

Los to() cláusulas se manejan correctamente: GET /objects me da la lista de objetos, y GET /objects/delete/42 borra el objeto 42.

El problema es que el permiso view objects se comprueba para ambas solicitudes, aunque la segunda ruta debe verificar el permiso delete objects.

La razón parece ser que /objects/delete/42 es una ruta debajo de /objects. El mismo problema no ocurre con la ruta /prefs, que no tiene una base común con las otras rutas.

Mi solución actual es colocar la regla para /objects debajo del uno por /objects/delete/:id, pero eso es a) unelegant y es b) va a romper cuando otro desarrollador edita el archivo. ¿Puedo desactivar explícitamente el comportamiento de anidamiento visto en este caso?

+2

Esto me parece un comportamiento bastante directo. Y su llamada solución temporal es una consecuencia lógica de cómo Mojolicious coincide con las rutas. OMI, respondió su pregunta. –

Respuesta

1

Los documentos Mojolicious parecen indicar que debe construir la ruta extendida fuera del objeto que maneja el más corto. Consulte la sección Nested Routes de los documentos.

Esto significa que tiene una ruta $ objects y una ruta $ objects_delete derivada de ella. Elimina los problemas de ordenación (además de tener que declarar la ruta más corta primero).

Cuestiones relacionadas