2011-08-23 13 views
7

Ho una semplice domanda: è possibile utilizzare l'autenticazione del digest con un XMLHTTPRequest?È possibile utilizzare l'autenticazione del digest con un XMLHTTPRequest?

Se la risposta è no, qual è il motivo tecnico? O se è possibile - come posso farlo?

Grazie mille ... Google non ha alcuna buona risposta finora: -/

EDIT:

Grazie per le risposte. La modifica dell'intestazione in modo che corrisponda allo schema di autenticazione del digest, dopo che è stato ricevuto un nonce, sembra essere una soluzione.

Ma quello che stavo veramente cercando era che potevo cambiare la mia chiamata corrente: xmlhttp.open ("GET", url, false, username, password); a sth. come xmlhttp.open ("GET", url, false, username, password, "DIGEST");

Fa parte anche della mia domanda iniziale: perché il metodo aperto non offre l'opzione per effettuare una richiesta di digestione?

Forse c'è js-lib che uno potrebbe raccomandare che mi permetta di farlo - come immagini che non voglio davvero cambiare l'unico e semplice xmlhttp.open a più richieste e prima ottenere un nonce.

+0

Cosa hai provato finora? Se la tua pagina del server richiede l'autenticazione Digest (restituendo un 401 alle richieste non autenticate) e si passa un nome utente e una password alla chiamata XHR open(), tutto dovrebbe funzionare correttamente. – EricLaw

+0

L'hai fatto? Sarei davvero apprezzato per il codice. Grazie! – vrunoa

risposta

8

Si può fare senza problemi. Basta seguire le parti delle specifiche che ritieni;)
http://tools.ietf.org/html/rfc2617
ed è tutto ciò che ti manca per iniziare a scrivere la tua libreria di autenticazione
http://pajhome.org.uk/crypt/md5/
sul lato client.

nome utente e password pre-scambio
Hey voglio autenticazione ----> Server
Ok ecco un nonce/sale ----> cliente
ecco un hash md5 somma di mio nome utente password timestamp e il sale -----> server
Ho appena inserito la password e il nome utente nello stesso modo in cui hai fatto e sono gli stessi -----> client
Quelle sono le basi di esso.

Ho omesso che è necessario includere l'URI della risorsa richiesta nell'hashsum !!!!
Ovviamente lo fai ad ogni richiesta che fai per una risorsa al server in questo modo qualcuno che intercetta l'hash può solo visualizzare il contenuto richiesto e non può effettuare una richiesta per una risorsa miscellanea. Questo metodo non protegge i dati basta accedervi.

+0

Non sono d'accordo. Chiunque può chiedere un nonce al server. Come vuoi trasportarlo in modo sicuro dal lato del cliente? – Chielus

+5

Non è solo per rendere più difficile capire la tua password da md5 e rendere ogni tentativo di autenticazione unico. http://en.wikipedia.org/wiki/Cryptographic_nonce. In questo modo, qualcuno non può man in mezzo al quale si ha l'hash e si autentica con esso in un altro momento. Infatti usano un nonce in Oauth. So cosa stai pensando che è ancora del tutto insicuro, ma lo scopo di questo tipo di autenticazione è solo quello di preservare il tuo nome utente e password. È molto semplice – Prospero

+0

:/Per cosa è stato votato per difetto? – Prospero

0

Il modo migliore per farlo è utilizzare SSL. Non penso che esista un'altra soluzione sicura (correggimi se sbaglio)

+1

Non sbagli solo cauto;) – Prospero

+1

Il digest è più sicuro di Basic + SSL! Scopri RFC 2617, la sezione sulla sicurezza. – wprl

+1

Senza SSL, un utente malintenzionato MitM (ad esempio, proxy ostile o compromesso, ad esempio in un punto di accesso WiFi pubblico) può inserire codice JavaScript arbitrario (o semplicemente collegamenti) nel codice HTML. In questo modo le richieste dell'attaccante verranno originate dal browser dell'utente, quindi il server non avrà alcuna possibilità di dire che queste sono _non_ dall'utente. L'utente malintenzionato non ha nemmeno bisogno di capire la password. – robert4

6

Dai un'occhiata a questo articolo: http://marcin-michalski.pl/2012/11/01/javascript-digest-authentication-restful-webservice-spring-security-javascript-ajax/. Spiega come eseguire il client JavaScript per l'autenticazione del digest con SpringSecurity sul lato server. Il codice è disponibile in github: https://github.com/Arrowgroup/JSDigestAuth

+0

Questa è la migliore risposta. Indicando il post di qualcuno che ha fatto tutto il lavoro e fornisce il codice sorgente completo (con un modo molto facile di testarlo) –

3

Ho codificato un flusso di lavoro completo per questo, non è affatto difficile una volta che si utilizza una libreria esterna per MD5 (utilizzo Crypto-js).

Il problema più grande che si può avere è che sul primo server 401 risponde che uno dei browser più utilizzati aprirà una finestra di dialogo per ottenere le credenziali.Per quanto ho visto non c'è un modo semplice per aggirare questo: How can I supress the browser's authentication dialog?

Per risolverlo, ho modificato il server web che ho codificato da un progetto C# codeplex. Alla prima richiesta il cliente passa un'intestazione "Avvertenza" che dice "Non aumentare un 401". Il server crea la sfida e la rimanda con una HttpException non-401 personalizzata (io uso 406 per il momento, che è "non accettabile" in HTTP). Il client crea l'hash e lo invia di nuovo.

Posso inserire alcuni frammenti di codice se qualcuno è interessato, questa è una specie di vecchia domanda.

+0

Questo non sembra essere vero per Safari, quando riceve 401 su un XHR. – wprl

+0

Cosa intendi con "questo"? "this" = "il browser apre una finestra di dialogo anche per XHR 401"? Se questo è il caso, non è necessario il trucco dell'intestazione di avviso. Soluzioni ampiamente compatibili richiederebbero comunque una soluzione alternativa. – malber

Problemi correlati