2011-07-16 6 views
35

Podczas korzystania z podstawowego uwierzytelniania HTTP nazwa użytkownika może zostać przekazana w adresie URL, np.Wywoływanie znaków użytkownika w podstawowych uwierzytelnionych adresach URL

http://[email protected]/path/ 

Ale teraz załóżmy, że nazwa użytkownika to adres e-mail, np. [email protected] Jest to wyraźnie dwuznaczne:

http://[email protected]@foo.com/path/ 

Czy istnieje sposób na uniknięcie znaku @ w nazwie użytkownika? Próbowałem standardowego kodowania adresu URL:

http://david%[email protected]/path/ 

Ale to się nie udało.

+0

Nie można użyć znaku @ w adresach URL. A może cię źle zrozumiałem? – Hnatt

+0

Wiem, że jestem trochę spóźniony na imprezę, ale czy po prostu przegapiłeś część z hasłem? standardowa składnia powinna być 'http (s): // user: pass @ host'. W twoim przypadku powinno to być 'http (s): //david%40company.com: Y0ur% 24up3r% 243cur3P% 40% 24% 24w0rd @ foo.com'. – FatalMerlin

+0

@FatalMerlin możesz mieć zarówno smak z samą nazwą użytkownika, jak i nazwą użytkownika i hasłem. Chociaż myślę, że jest to ortogonalne w kwestii ucieczki. –

Odpowiedz

52

Według RFC 3986, sekcja 3.2.1, musi być zakodowany procent:

userinfo = *(unreserved/pct-encoded/sub-delims/":") 

Tak wygląda

http://david%[email protected]/path/ 

ma rację. Gdzie próbujesz to przeczytać? Może musisz ręcznie odkodować wartość?

+0

Mam swój własny kod po stronie serwera, który przetwarza poświadczenia. Muszę go debugować i zobaczyć dokładnie, co otrzymuję, kiedy uciekam w ten sposób. Będę śledzić! –

+2

Klienci nie wydają się dobrze komponować z tą składnią. na przykład IE9 blokuje go przed wysłaniem jakiegokolwiek żądania i wyświetla błąd "Windows nie może znaleźć" http: //david%[email protected]/path/ ". Sprawdź pisownię i spróbuj ponownie.". To prowadzi mnie do przekonania, że ​​ta składnia nie jest faktycznie obsługiwana, pomimo tego, co może wydawać się z RFC. –

+0

Działa dobrze przy użyciu loków ... –

Powiązane problemy