BrowserID e HTTPS in conflitto?

1

La mia app web-flask utilizzava BrowserId . Quando ho provato a estendere ulteriormente la mia app reindirizzando tutte le richieste in arrivo a HTTPS . Il reindirizzamento HTTPS ha funzionato correttamente, ma ora la funzione di accesso ha come risultato:

login failure: error

Che cosa sta causando questo problema? Cosa posso fare per risolverlo? Nel caso in cui sia importante, ecco la mia webapp. . Sto schierando su heroku usando Gunicorn come server. Ecco i log di heroku per un accesso non riuscito

    
posta Drew Verlee 08.01.2013 - 20:46
fonte

2 risposte

1

Non ho familiarità con Flask, ma ho il sospetto che ciò potrebbe essere dovuto a un problema con il reindirizzamento di una richiesta POST . In particolare il POST richiede che il front-end mandi al back-end per verificare l'asserzione.

Una cosa che potresti provare (per testare la teoria di cui sopra) è che la tua applicazione non ascolti sulla porta 80 e solo sulla 443. In questo modo non ci sarà un mix di HTTP e HTTPS e flask-sslify non avrà per reindirizzare qualsiasi cosa.

    
risposta data 08.01.2013 - 23:15
fonte
0

Una cosa che puoi provare è provare a modificare il client, a POST direttamente su HTTPS.

Sembra che ciò che potrebbe accadere in questo momento sia che il client stia eseguendo il POST su un URL HTTP; quindi flask-sslify riceve la richiesta HTTP, risponde al client con un reindirizzamento e attiva il client per inviare nuovamente la richiesta POST a un URL HTTPS.

Dovresti essere in grado di verificare se questo è cosa sta accadendo usando, ad es. Firebug o Wireshark o qualsiasi altro strumento che ti permetta di vedere quali richieste sta facendo il cliente.

Se questo è ciò che sta accadendo giusto, una cosa che potresti provare è cambiare il client in modo che sia POST tramite HTTPS direttamente. In altre parole, provare a cambiare il client in modo che la richiesta POST iniziale venga inoltrata su HTTPS, in modo che non vada mai su HTTP e non attivi mai un reindirizzamento. Vorrei suggerire di provare questo, per vedere se questo fa andare via il problema. Se fa scomparire il problema, dà qualche indizio su dove potrebbe trovarsi il problema (forse il client non gestisce i reindirizzamenti per i POST nel modo in cui vorresti, o forse c'è un problema in flask-sslify; caso, è un indizio gigante che dovrebbe aiutare a risolvere il problema).

Puoi verificare se hai avuto successo nel garantire che il client invii il POST inizialmente su HTTPS in primo luogo, utilizzando gli stessi strumenti di debug (ad es. Firebug o Wireshark).

In generale, avere il client che utilizza HTTPS direttamente (se possibile) è meglio che affidarsi a reindirizzamenti avviati dal server per reindirizzare il client da HTTP a HTTPS. Semplifichera le cose ed è anche più sicuro. (Se il client invia la sua richiesta iniziale su HTTP, e ti affidi a un reindirizzamento avviato dal server, sarai comunque vulnerabile agli attacchi man-in-the-middle. Se la richiesta iniziale del client è su HTTPS, allora sei non vulnerabile agli attacchi man-in-the-middle.) È possibile che la semplificazione di cose come questa potrebbe causare la scomparsa del bug, e non dovrebbe essere troppo difficile verificare se sia effettivamente così.

D'altra parte, se il tuo cliente è già POST direttamente in HTTPS (se il tuo client non invia mai alcuna richiesta HTTP in primo luogo, e non c'è alcun reindirizzamento sul lato server), allora io avere la più pallida idea di cosa sta succedendo.

    
risposta data 09.01.2013 - 21:43
fonte

Leggi altre domande sui tag