2015-11-18 21 views
9

Quando eseguo l'autenticazione del solito modo (utilizzando il modulo di accesso), funziona perfettamente. Sto ottenendo questo errore solo quando /check_form si accede tramite metodo GET direttamente, nel qual caso viene generata un'eccezione:Come eliminare l'errore "È necessario configurare il percorso di controllo da gestire dal firewall" con le richieste GET?

È necessario configurare il percorso di controllo per essere gestita dal firewall utilizzando form_login nella configurazione del firewall di sicurezza.

Ecco il relativo security.yml parte:

firewalls: 
    acme_area: 
     pattern: ^/(acme|admin)/ 
     provider: fos_userbundle 
     form_login: 
      provider: fos_userbundle 
      csrf_provider: form.csrf_provider 
      login_path: acme_login 
      check_path: /acme/login_check 
     logout: 
      path: /acme/logout 
      target: acme_login 
     anonymous: true 

sto usando 2.3, quindi nessuna opzione methods è applicabile (anche se non ho idea se sarebbe d'aiuto).

non è davvero un problema in quanto non corretto utilizzo potrebbe essere rovinato da questo errore, ma inquina il log degli errori quando alcuni bot diligente sta visitando il sito ed è solo in disordine. Quindi, vorrei sapere quale opzione di configurazione posso modificare per eliminare questo errore.

Per bollire questo, sembra che io voglia gettare qualche errore 4xx invece di 500. Idealmente dovrebbe essere 405 Method Not Allowed, ma anche il freddo 404.

EDIT:

Per come ho imparato dalla risposta di Alex in basso, questo accade perché le richieste POST vengono gestite dal firewall e ottenere le richieste del controllore. Quindi, sembra che il default checkAction() devono essere estese per essere in grado di gestire due casi:

  1. Quando la richiesta è POST, ma nessuna voce firewal è presente (già nandled)
  2. Quando la voce firewall è presente, ma alla richiesta non è GET (il mio caso)
+0

Probabilmente avete già visto e digerito le informazioni qui? http://stackoverflow.com/questions/17406446/how-does-the-login-check-path-route-work-without-default-controller-action – RamRaider

risposta

8

Non esiste un'opzione di configurazione per questo. Se la richiesta raggiunge il controller, genera incondizionatamente l'eccezione: credible source.

POST richiesta per il percorso sono gestiti da firewall: official docs; GET quelli vanno al controller come al solito.

Ci sono poche opzioni per eliminare l'errore nel registro, se non ti interessa di tali eventi. Il più semplice a mio avviso è di ignorare SecurityController::checkAction per restituire 500 errori senza generare un'eccezione. Il documento ufficiale come raggiungerlo: Overriding Default FOSUserBundle Controllers.

EDIT:

Nel controllore è possibile restituire qualsiasi codice che ti piace:

public function checkAction() 
{ 
    return new Response('', 418); // or better use Response constants 
} 

Un altro modo è quello di disabilitare metodo GET per /acme/login_check nella configurazione di routing, e lasciare che il router fare il suo lavoro e restituire normalmente il numero 405 Method Not Allowed.

EDIT2:

È possibile analizzare richiesta nell'azione, ed ancora un'eccezione:

public function checkAction(Request $request) 
{ 
    if ($request->getMethod() == Request::METHOD_POST) { 
     throw new \RuntimeException('You must configure the check path to be handled by the firewall using form_login in your security firewall configuration.'); 
    } else { 
     return new Response('', Response::HTTP_METHOD_NOT_ALLOWED); 
    } 
} 

ma consiglierei di eseguire il debug i percorsi, invece. Questa logica dovrebbe appartenere al router, non al controller. A lungo termine, la configurazione di routing ingannerà gli sviluppatori che manterranno questo codice e avranno parecchie ore di debug che cercano di capire perché restituisce 405, quando app/console debug:router indica chiaramente che il metodo GET è consentito.

+0

Ma perché non usa il metodo POST? E perché dovrei prendermi cura di questi eventi? Forse la mia comprensione del flusso è semplicemente sbagliata. Non può essere un problema di routing e quindi risolto risolvendo le rotte? La "fonte credibile" non è in realtà mia. È stato aggiunto automaticamente, mentre cercavo la risposta. –

+0

Ehi, senza offesa per "documenti ufficiali". Non riuscivo a trovare un titolo migliore per i collegamenti. Ho aggiunto la parola 'POST' alla risposta. Probabilmente non dovresti preoccuparti dei robot, ma non tutti i robot sono altrettanto stupidi. Preferisco tenere i registri per ogni evenienza. Non ci sono problemi con le rotte. È esattamente come è implementato, ma puoi esplicitamente sovrascrivere 'GET/acme/login_check' se ti piace indirizzarlo da qualche altra parte. –

+0

Aha, è davvero d'aiuto sapere per un tale noob come me. Quindi, per me risulta essere il problema del routig, poiché nessun firewall è coinvolto. Supponendo che non ci sia uno scenario GET corretto per/login_check, non puoi proporre la soluzione che farà 403 o 404 quando/login_check è richiesto tramite GET (come 500 è sicuramente sbagliato qui)? O anche 405 se possibile –