Passport.js + Express.js przekazuje użytkownika do pierwotnego miejsca docelowego po uwierzytelnieniu

Question

Mam aplikację, która jest węzłem + Express + paszport na serwerze i jQuery + Backbone.js na kliencie. Klient korzysta z tagów skrótu w adresie URL, ale dla niektórych funkcji ważne jest, aby użytkownik był zalogowany.

Chciałbym, aby aplikacja była dostępna za pośrednictwem adresu URL, np. http://mydomain.com/app#cone/waffle/flavor/mint/toppings/sprinkles takie, że:

• jeśli użytkownik jest już zalogowany, idą do żądanego adresu URL bezpośrednio bez kłopotów
• jeśli użytkownik nie jest już zalogowany, idą do /login a następnie przejdź do żądanego adresu URL

po tym SO post, Custom returnUrl on Node.js Passport's Google strategy, mam go tak, że

• Jeśli są one rejestrowane w już idą d irectly URL, tagi cebulą i wszystko
• Jeśli nie były one rejestrowane, to bierze je do strony logowania, a następnie do żądanego adresu URL, ale ...

Wydaje się rozebrać hash parametry z oryginalnego adresu URL przekierowania po zalogowaniu.

Czy istnieje sposób na zachowanie parametrów skrótu podczas przekierowywania ich do pierwotnego miejsca docelowego?

Z tego posta, Getting hash parameters from request url, wynika, że ​​znaczniki hash nie są dostępne na serwerze, co stanowi cały sens używania tagów hash.

Podejrzewam, że nie jest to możliwe. Może jakoś lokalnie buforujesz parametry i pobierasz je w przekierowaniu, powiedzmy do [original URL minus hastags] + #use-cached-params?

Answer 1

Parametry skrótu są dostępne tylko w przeglądarce, nie przechodzą na serwer. Możesz użyć tej techniki chociaż na przekierowanie z powrotem, hash-tagi i wszystkie:

• GET/some/strona # z/hash
• zalogowany? następnie renderować stronę niezalogowaną? renderowanie strony, która ma pewne JavaScript na nim, powiedzieć 'getHash.jade'
• getHash.jade: kopiuje pełny adres URL, a następnie przekierowuje do '/ login & przekierowanie =' + originalURL
• GET/login (teraz można zapisz hasz na serwerze i pobierz go stamtąd)

Answer 2

Oto, jak uchwycić linki kotwiczne w nieco bardziej szczegółowym miejscu. Działa we wszystkich frameworkach internetowych.

użyję przykładowy scenariusz do zilustrowania: powiedzmy, że musimy uchwycić głęboki adresu URL http://server.com/#/xyz wymagane przez niezidentyfikowany użytkownik tak, że mogą być przekierowany do tego głęboko URL post-logowania.

1. nieuwierzytelniony użytkownik zażąda http://server.com/#/xyz (wszystko od '#' roku nie jest wysyłana do serwera).

2. Cały serwer wie, że użytkownik chce uzyskać http://server.com/ i że jest nieuwierzytelniony. Serwer przekierowuje użytkownika do formularza logowania.

3. Oto sprytny bit: klient wciąż czeka na swojego pierwotnego wniosku, więc jeśli serwer zawiera ukryty element formularza logowania z niektórych JS że odniesienia window.location.href może uchwycić pełny adres URL z oryginalna prośba zakończyć z częścią kotwicy:

   <form action="/login" method="post"> 
       <div> 
       <label>Username:</label> 
       <input type="text" name="username"/><br/> 
       </div> 
       <div> 
       <label>Password:</label> 
       <input type="password" name="password"/> 
       </div> 
       <!-- XXXXXXXXX CLEVER BIT XXXXXXXXXX--> 
       <script> 
       document.write('<input type="hidden" name="from" value="'+document.location.href+'"/>'); 
       </script> 
       <!-- XXXXXXXXXX--> 
       <div> 
       <input class="submit-button" type="submit" value="Submit"/> 
       </div> 
   </form> 
   

4. użytkownik uwierzytelnia samym sobą i oryginalny adres URL jest przesyłany ze stanowiskiem. Serwer może następnie przekazać użytkownika do oryginalnego głębokiego adresu URL.