Invio di richiesta POST ad azione protetta

Question

Ho un'azione che richiede i dati POST protetti da sfGuard. Ciò significa che se l'utente non ha effettuato l'accesso, i dati POST verranno inviati al modulo di accesso. Normalmente, questo non è un problema, l'utente continua ad accedere e deve inviare nuovamente i dati.

Sfortunatamente, il modulo di accesso sembra utilizzare i dati POST come se fosse stato inviato con il modulo stesso. Ciò significa che si lamenta del fatto che mancano i campi del nome utente e della password richiesti e si lamenta che manca un token CSRF. Questo ultimo problema non scompare, dopo aver inviato il modulo, il che significa che l'utente non può accedere, comunque.

L'utente non deve essere presentato con il modulo se non ha effettuato l'accesso, ma potrebbe essere possibile per l'utente effettuare il logout con il modulo ancora aperto. Quindi sto chiedendo nell'interesse di mantenere l'interfaccia stagna e priva di errori.

Si tratta di una mancanza di sfGuard, può essere evitata oppure sto facendo qualcosa di sbagliato?

Per chiarire, il percorso si presenta così:

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] 

Il modulo utilizzato nel sottoporre la richiesta è la seguente:

<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> 

Answer 1

Si tratta di una mancanza di sfGuard, perché l'azione di accesso verificherà la presenza di una richiesta POST e, in caso affermativo, vincerà il modulo.

Dal codice in BasesfGuardActions.class.php:

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

Io non sono personalmente un grande fan di inoltro tra le azioni in symfony, e proprio come in questo caso, penso che sia più appropriato per reindirizzare che avanti. Questo risolve anche il tuo problema perché ciò comporterà una nuova richiesta GET. È possibile eseguire questo comportamento estendendo 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(); 
    } 

} 

Ora, in app/frontend/config/filters.yml

security: 
    class: mySecurityFilter 

Answer 2

Questo è probabilmente perché si mette il codice di autenticazione del login dati nella stessa azione (verificando a priori se la richiesta è post).

Tuttavia è possibile dividere l'azione in due azioni. Uno per mostrare il modulo di accesso e l'altro per autenticare i dati di accesso dell'utente. E imposta il tuo secure_action all'azione che è solo per mostrare il modulo di login.