2011-08-17 17 views
9

Tengo una acción que toma los datos POST asegurados por sfGuard. Esto significa que si el usuario no está conectado, los datos POST se enviarán al formulario de inicio de sesión. Por lo general, esto no es un problema, el usuario continúa ingresando y tiene que volver a enviar los datos.Envío de solicitud POST a acción segura

Desafortunadamente, el formulario de inicio de sesión parece estar utilizando los datos de POST como si se hubiera enviado con el formulario. Esto significa que se queja de que faltan los campos requeridos de nombre de usuario y contraseña, y se queja de que le falta un token CSRF. Este último problema no desaparece, después de enviar el formulario, lo que significa que el usuario no puede iniciar sesión de todos modos.

El usuario no debe recibir el formulario si no ha iniciado sesión, pero es posible que el usuario cierre la sesión con el formulario aún abierto. Por lo tanto, pregunto con el interés de mantener la interfaz a prueba de agua y sin errores.

¿Es esto una deficiencia de sfGuard, se puede evitar, o estoy haciendo algo mal por completo?

Para aclarar, la ruta se ve así:

add_subgroup: 
    url:  /group/:id/add 
    class: sfPropelRoute 
    options: 
    model: Group 
    type: object 
    param: { module: subgroups, action: create } 
    requirements: 
    group_id: \d+ 
    sf_method: [post] 

La forma utilizada para presentar la solicitud es el siguiente:

<form action="<?php echo url_for('add_subgroup', $group) ?>" method="post"> 
    <input type="hidden" name="group_id" value="<?php echo $group->getId() ?>" /> 
    <input type="text" name="subgroup_id" /> 
    <input type="submit" class="button" value="Add" /> 
</form> 
+0

puede ser más específico está tratando de hacer un formulario de acceso o qué? – Henry

+0

Estoy intentando llamar a una acción segura. Si el usuario no está conectado, va a un formulario de inicio de sesión existente. Como la acción requiere datos POST, estos datos POST están interfiriendo con el formulario. ¿Puedes ser más específico con respecto a lo que debería ser más específico? – Druckles

+0

¿Cómo lo está manejando si el usuario no ha iniciado sesión? Si emite una redirección de encabezado, los datos POST deben borrarse. si en su lugar lo está incluyendo, entonces los datos POST estarán presentes. –

Respuesta

6

Es un defecto de sfGuard, porque la acción de inicio de sesión verificará una solicitud POST, y si es así, enlazará el formulario.

Desde el código en BasesfGuardActions.class.php:

if ($request->isMethod('post')) 
{ 
    $this->form->bind($request->getParameter('signin')); 

no soy personalmente un gran fan de reenvío entre las acciones en Symfony, y al igual que en este caso, creo que es más apropiado para redirigir de adelante. Esto también resuelve su problema porque esto dará como resultado una nueva solicitud GET. Puede lograr este comportamiento ampliando sfGuardBasicSecurityFilter.

class mySecurityFilter extends sfGuardBasicSecurityFilter 
{ 

    protected function forwardToLoginAction() 
    { 
    $context = $this->getContext(); 
    // If you want to redirect back to the original URI (note: original POST data will be lost) 
    $context->getUser()->setReferer($context->getRequest()->getUri()); 
    $url = sfConfig::get('sf_login_module') . '/' . sfConfig::get('sf_login_action'); 
    $context->getController()->redirect($url); 
    throw new sfStopException(); 
    } 

} 

Ahora en app/miaplicacion/config/filters.yml

security: 
    class: mySecurityFilter 
0

Esto es probablemente porque se pone el código de autenticación del inicio de sesión datos en la misma acción (probally por cheque si la solicitud es posterior).

Sin embargo, podría dividir una acción en dos acciones. Uno para mostrar el formulario de inicio de sesión, y el otro es para autenticar los datos de inicio de sesión del usuario. Y configure su secure_action en la acción que es solo para mostrar el formulario de inicio de sesión.

Cuestiones relacionadas