UTF-8 znaków w HTTP Basic Auth username
Próbuję zbudować serwis internetowy używając Ruby on Rails. Użytkownicy uwierzytelniają się za pomocą HTTP Basic Auth. Chcę zezwolić na wszystkie ważne znaki UTF-8 w nazwach użytkowników i hasłach.
Problem polega na tym, że przeglądarka zniekształca znaki w podstawowych poświadczeniach Auth, zanim wyśle je do mojego serwisu. Do testowania, używam "カカカナカカカカカカカカカカ' '''''''''''''''" jako moja nazwa użytkownika (Nie wiem, co to znaczy-AFAIK to niektóre losowe znaki nasz QA guy wymyślił - proszę mi wybaczyć jeśli jest to w jakiś sposób obraźliwe).
If I take that as a string and do username.rozpakuj ("h*") aby przekonwertować go na hex dostaję: '3e28ba3e28fb3e28ba3e38a83e28ba3e28fb3e28ba3e38a83e28ba3e28fb3e28ba3e38a83e28ba3e28fb3e28ba3e38a83e28ba3e28fb3e28ba3e38a83e28ba3e28fb3e28ba3e38a83e28ba3e28fb3e28ba3e38a83e28ba3e28fb3e28ba3e38a8' wydaje się, że pasuje do 32 znaków kanji (3 bajty/6 cyfr hex NA).
Jeśli zrobię to samo z nazwą użytkownika, która przychodzi poprzez HTTP basic auth, I get: "bafbbaacbafbbaacbafbbaacbafbbaacbafbbaacbafbbaacbafbbaacbafbbaacbafbbaacbafbbaac". Jest oczywiście znacznie krótszy. Używając wtyczki Firefox Live HTTP Headers, oto rzeczywisty nagłówek, który jest wysyłany:
Authorization: Basic q7+ryqu/q8qrv6vKq7+ryqu/q8qrv6vKq7+ryqu/q8o6q7+ryqu/q8qrv6vKq7+ryqu/q8qrv6vKq7+ryqu/q8o=
To wygląda tak 'bafbba...'string, z podmienionymi nibblesami high I low (przynajmniej jak wkleję to do Emacsa, base 64 dekoduje, potem przełączy się na tryb hexl). To może być reprezentacja UTF16 nazwy użytkownika, ale nie dostałem nic, aby wyświetlić go jako cokolwiek, ale bełkot.
Rails ustawia nagłówek content-type na UTF-8, więc przeglądarka powinna wysyłać w tym kodowaniu. Otrzymuję poprawne dane do przesłania formularza.
Problem występuje zarówno w Firefoksie 3.0.8 jak i IE 7.
Więc... czy jest jakiś magiczny sos do zmuszania przeglądarek internetowych do wysyłania znaków UTF-8 przez HTTP basic Auth? Czy źle znoszę rzeczy po stronie odbiorczej? Czy HTTP Basic Auth po prostu nie działa ze znakami spoza ASCII?6 answers
Porzuć wszelką nadzieję. Podstawowe uwierzytelnianie i Unicode nie mieszają się.Chcę zezwolić na dowolne ważne znaki UTF-8 w nazwach użytkowników i hasłach.
Nie ma standardowego (*) sposobu kodowania znaków innych niż ASCII do podstawowego tokenu uwierzytelniania username:password przed użyciem Base64. W związku z tym każda przeglądarka robi coś innego:
- Opera używa UTF-8;
- IE używa domyślnej strony kodowej systemu (której nie masz możliwości poznać, poza nie jest to UTF-8), i po cichu manipuluje postaciami, które nie pasują do niego za pomocą systemu Windows "Odgadnij losową postać, która wygląda trochę jak ta, którą chciałeś, a może po prostu nie" sekretny przepis; {]} Mozilla używa tylko dolnego bajtu znaków kodowych, co powoduje kodowanie do ISO-8859-1 i nieodwracalne zniekształcanie znaków innych niż 8859-1... z wyjątkiem podczas wykonywania Xmlhttprequestów, w którym to przypadku używa UTF-8;
- Safari i Chrome kodują do ISO-8859-1, oraz nie można w ogóle wysłać nagłówka autoryzacji, gdy używany jest znak inny niż 8859-1.
*: niektórzy interpretują standard mówiąc, że albo:
- powinno być zawsze ISO-8859-1, ponieważ jest to domyślne kodowanie dla włączania surowych znaków 8-bitowych bezpośrednio zawartych w nagłówkach;
- powinno być zakodowane przy użyciu reguł RFC2047, w jakiś sposób.
Ale żadna z tych propozycji nie jest na temat włączenia do kodowanego w base64 tokena auth, a RFC2047 odwołanie w specyfikacji HTTP naprawdę nie działa, ponieważ wszystkie miejsca, w których może być użyte, są wyraźnie zabronione przez reguły' ATOM context ' samego RFC2047, nawet jeśli nagłówki HTTP przestrzegają reguł i rozszerzeń rodziny RFC822, czego nie robią.
W podsumowaniu: Nie ma najmniejszej nadziei na to, że zostanie to kiedykolwiek naprawione w Standardzie lub w przeglądarkach innych niż Opera. To tylko jeszcze jeden czynnik odciągający ludzi od podstawowego uwierzytelniania HTTP na rzecz niestandardowe i mniej dostępne schematy uwierzytelniania oparte na plikach cookie. Naprawdę szkoda.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-03-31 22:39:30
Znane jest niedociągnięcie, że podstawowe uwierzytelnianie nie zapewnia obsługi znaków innych niż ISO-8859-1.
Niektóre UA są znane z tego, że zamiast tego używają UTF-8( przychodzi mi na myśl Opera), ale do tego też nie ma interoperacyjności.
Z tego, co wiem, nie ma sposobu, aby to naprawić, z wyjątkiem zdefiniowania nowego schematu uwierzytelniania, który obsługuje cały Unicode. I rozlokowanie.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-03-31 20:19:20
Uwierzytelnianie HTTP Digest również nie jest rozwiązaniem tego problemu. Ten sam problem polega na tym, że Klient nie jest w stanie powiedzieć serwerowi, jakiego zestawu znaków używa, a serwer nie jest w stanie poprawnie przyjąć tego, czego użył klient.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2010-08-20 20:16:57
Czy testowałeś używając czegoś takiego jak curl, aby upewnić się, że nie jest to problem z Firefoksem? HTTP AUTH RFC milczy na ASCII vs. non-ASCII, ale mówi, że wartość przekazana w nagłówku to nazwa użytkownika i hasło oddzielone dwukropkiem, a ja nie mogę znaleźć dwukropka w łańcuchu, który Firefox zgłasza wysyłanie.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-03-31 19:41:36
Jeśli kodujesz dla systemu Windows 8.1, zauważ, że próbka w dokumentacji HttpCredentialsHeaderValue jest (błędnie) używana w kodowaniu UTF-16. Dość dobrą poprawką jest przejście na UTF-8 (ponieważ ISO-8859-1 nie jest obsługiwany przez CryptographicBuffer.ConvertStringToBinary).
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2013-10-23 17:30:57
Mogę być kompletnym ignorantem, ale przyszedłem do tego postu, szukając problemu podczas wysyłania ciągu UTF8 jako nagłówka wewnątrz połączenia ajax.
Mógłbym rozwiązać mój problem poprzez zakodowanie w Base64 ciągu tuż przed wysłaniem go. Oznacza to, że możesz za pomocą prostego JS przekonwertować formularz do base64 tuż przed przesłaniem i w ten sposób można go ponownie przenieść po stronie serwera.
Te proste narzędzia pozwoliły mi na wysyłanie ciągów utf8 jako prostych ASCII. I found that dzięki temu prostemu zdaniu:
Base64 (to kodowanie jest zaprojektowane tak, aby dane binarne przetrwały transport przez warstwy transportowe, które nie są czyste 8-bitowo). http://www.webtoolkit.info/javascript-base64.html
Mam nadzieję, że to jakoś pomoże. Po prostu staram się oddać trochę społeczności!
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2011-09-29 03:01:03