Puoi passare utente / passaggio per l'autenticazione di base HTTP nei parametri URL?

153

Credo che questo non sia possibile, ma qualcuno che conosco ha insistito sul fatto che funzioni. Non so nemmeno quali parametri provare e non l'ho trovato documentato da nessuna parte.

Ho provato http://myserver.com/~user=username&password=mypassword ma non funziona.

Potete confermare che in realtà non è possibile passare l'utente / passare tramite parametri HTTP (GET o POST)?

authentication http http-basic-authentication

— ripper234
fonte

9

utente: pass@example.com

— Smudge

@sam - che cosa? Come sarebbe l'URL completo?

— ripper234

4

Tutto nelle specifiche ietf.org/rfc/rfc1738.txt (3.1)

— Smudge

@sam - Mi dispiace, non ho ancora analizzato il tuo commento per qualche motivo.

— ripper234

200

Non è infatti possibile passare il nome utente e la password tramite parametri di query nell'autenticazione HTTP standard. Invece, si utilizza un formato URL speciale, come questo: http://username:password@example.com/- questo invia le credenziali nell'intestazione HTTP "Autorizzazione" standard.

È possibile che chiunque stia parlando stia pensando a un modulo o codice personalizzato che ha esaminato i parametri della query e verificato le credenziali. Questa non è un'autenticazione HTTP standard, tuttavia, è una cosa specifica dell'applicazione.

— womble
fonte

1

Grazie, questo è proprio quello che stavo cercando ... non è fondamentale che si tratti di parametri GET, solo che posso trasformarlo nell'URL.

— ripper234

42

Cordiali saluti, il http://username:password@example.comformato non è più supportato da IE o Chrome , non sarebbe sorpreso se altri seguissero l'esempio se non lo hanno già fatto.

— TJ Crowder,

11

Funziona davvero bene in Chrome. Solo IE è un marmocchio viziato.

— Damien Overeem ツ

1

@DamienOvereem su quale versione di Chrome hai? sono su Mac OS X 37 e non sembra funzionare per me

— Chris DaMour,

11

Da allora ho appreso che Chrome lo aveva disabilitato per un po ', ma in seguito ho riattivato questa funzione. Ho anche appreso che Safari genererà errori di phishing quando si imbattono in questi tipi di collegamenti .. Fondamentalmente il tempo dell'autenticazione http basata su url è finito ..

— Damien Overeem ツ

18

Passaggio di parametri di autenticazione di base nell'URL non consigliato

Esiste un campo di intestazione di autorizzazione a tale scopo verificarlo qui: elenco di intestazioni http

Come usarlo è scritto qui: Autenticazione dell'accesso di base

Lì puoi anche leggere che sebbene sia ancora supportato da alcuni browser, la soluzione suggerita di aggiungere le credenziali di autorizzazione di base nell'URL non è raccomandata.

Leggi anche il capitolo 4.1 in RFC 2617 - Autenticazione HTTP per maggiori dettagli sul perché NON usare l'autenticazione di base.

Passando i parametri di autenticazione nella stringa di query

Quando si utilizza OAuth o altri servizi di autenticazione, spesso è anche possibile inviare il token di accesso in una stringa di query anziché in un'intestazione di autorizzazione, quindi qualcosa di simile:

GET https://www.example.com/api/v1/users/1?access_token=1234567890abcdefghijklmnopqrstuvwxyzABCD

— Appassire
fonte

E come si fa a codificare un'intestazione di autorizzazione in un URL?

— womble

2

Il modulo che hai dichiarato non è ora obsoleto?

— Womble

2

La domanda a cui hai risposto con "Esiste un campo di intestazione di autorizzazione per questo scopo" è stata la domanda su come inserire i parametri di autenticazione nell'URL . Se non riesci a codificare i campi dell'intestazione HTTP in un URL (cosa impossibile), la tua risposta è non sequitur.

— womble

Puoi citare dove lo standard URI afferma che il passaggio dei parametri di autenticazione di base in URI è deprecato? RFC 2396 afferma solo che "NON È RACCOMANDATO" perché i dettagli di autenticazione in testo normale non sono, in molte circostanze, una buona idea (di cui sono d'accordo), mentre RFC 7235 non menziona nulla. Da nessuna parte nelle specifiche che posso cercare si dice che è deprecato.

— Lie Ryan,

1

@Wilt: devo scusarmi, hai davvero ragione. Il tuo suggerimento che la specifica sia stata "modificata" mi ha spinto a indagare ulteriormente (una RFC non viene mai modificata una volta pubblicata / numerata). Ho appena scoperto che RFC 2396 è stato effettivamente sostituito da RFC 3986 , che non sono stato in grado di trovare prima. RFC 3986 menziona la deprecazione del nome utente: sintassi della password:Use of the format "user:password" in the userinfo field is deprecated.

— Lie Ryan,

17

http: // nome utente: password@example.com funzionerà per FireFox, Chrome, Safari MA non per IE.

Microsoft Knowledge Base

— Girish Kumar
fonte

2

Questa funzionalità è stata rimossa da Chrome 19+. Vedi code.google.com/p/chromium/issues/detail?id=123150

— Moshe Katz

4

Dalla mia lettura di quel bug report, è stato aggiunto di nuovo in Chrome 20. Sicuramente, mi aspetto di vedere molti continui lamentarsi a riguardo se non fosse stato.

— womble

Ora l'ho richiesto per Internet Explorer: connect.microsoft.com/IE/feedback/details/873575/… . Caso d'uso leggermente diverso, ma risolve lo stesso problema;)

— SimonSimCity

@Diago se la password contiene '@' allora non funziona. dà un errore fatale, qualcuno può dirmi come possiamo dare nome utente e password contemporaneamente

— Ashish Jain

@AshishJain - Proverei a sfuggire @alla password come %40. (Non so se funziona, e potrebbe dipendere dal server o dalla combinazione browser / server.)

— David Moles

0

È (ovviamente) possibile inviare qualsiasi stringa nei parametri GET, anche se non è consigliabile inviare login e password in quanto può renderlo altamente visibile, soprattutto se non è in una richiesta AJAX.

Sarà quindi necessario codificare la pagina del server per estrarre il login e la password, quindi convalidarli e utilizzarli nel modo richiesto.

— Steve Smith
fonte