While implementing login with session restore (docs) we’ve encountered some issues and had to hack our way around them. Therefore we wonder, if we missed something, or if this is the intended way to do it.
We currently have a scenario similar to this:
on /login the user first logins with redirectUrl: "/"
later on the user visits /other, thus requiring a session restore
the handleIncomingRequest call restores the session and redirects to / (it reuses the redirectUrl from login)
the application itself has to change the page to /other without reloading the page (or else we need the session restore again)
For the application code, this means before calling handleIncomingRequest, we need to store the current location, and on success fetch it from the storage and navigate back to this location. For applications, which are not single-page-applications, this seems entirely impossible. For ours, it is possible, but inconvenient and far from intuitive.
Is there a cleaner solution to this, than the one we found?
I guess we didn’t see the 2nd part of the documentation (link). One can use the onSessionRestore(previousUrl => /* set location to previousUrl without reloading the page */) callback, so we don’t need to manually store the previous location.
Correct, onSessionRestore or the “sessionRestore” event on the Session class will handle returning the user to the correct path post-silent authentication, however, if you need to go from /other -> application login page -> IdP (interactive authentication), then you’ll need to store the “return to” URL manually, as this isn’t handle by the SDK; For instance, here’s how we currently do it in Pod Browser:
Thanks for sharing how it is done in the PodBrowser. I think we won’t use an intermediate login page in our application, but I’m sure it could be helpful for others!
The main point is that whatever calls session.login would have to persist the current URL somewhere before doing so, and then after the login event, you’ll need to fetch that value and change URL to that using history replaceState; login currently does not automatically do that for you, unlike sessionRestore.
We do have something in our backlog about allowing the user to store data through the redirect flow. With oAuth this would be via the state parameter, but at present we use that value internally & don’t allow the user to set it, hence having to rely on storing state before initiating a login.