Mam system dwuserwerowy ... jeden obsługujący aplikację, a drugi obsługujący uwierzytelnianie / autoryzację. Gdy aplikacja wykryje, że użytkownik nie jest jeszcze zalogowany, przekierowuje na serwer autoryzacji i przekazuje jako parametr adres URL pierwotnie żądany przez użytkownika, dzięki czemu po uwierzytelnieniu użytkownik zostanie przekierowany z powrotem do serwera aplikacji do dokładny adres URL pierwotnie wymagany.

Jeśli jednak ten oryginalny adres URL zawiera numer #, cała procedura zostanie przerwana. Wygląda na to, że przeglądarki dekodują parametr zakodowany w url iw konsekwencji upuszczają wszystko po numerze na podłogę. Próbowałem tego w Chrome, Safari i Firefox.

Przykład:

Oryginalny adres URL:

https://xxx.com/#/main/by-users?param1=53&param2=13&param3=39

Adres URL przekierowania:

https://yyy.com/signin/?returnURL=https%3A%2F%2Fxxx.com%3A80%2F%23%2Fmain%2Fby-users%3Fparam1%3D53%26param2%3D13%26param3%3D39

Pokazy przeglądarki:

https://yyy.com/signin/?returnURL=https%3A%2F%2Fxxx.com%2F#/main/by-users?param1=53&param2=13&param3=39

Jak widać, wszystko w tym i po dekodowaniu #. W ten sposób serwer nigdy nie otrzymuje pełnej wartości parametru „returnURL”. Zasadniczo po prostu dostaje

https://xxx.com/

Musi to być część jakiegoś spec, gdzieś, chociaż wydaje się szalone, że zakodowany # powinien być dekodowany i traktowany tak, jakby nigdy nie był zakodowany. Ale jak sobie z tym poradzić?

Dzięki.