LoginRocket includes a number of features related to redirecting users and getting them to exactly the place you want them to end up.
A basic LoginRocket configuration doesn’t require any special handling of redirects. You can simply configure the Login Handler URL and users will be able to successfully login. The basic workflow looks like this:
User clicks on a Login link, which goes to https://yourapp.e1.loginrocket.com/login.
LoginRocket displays the login form.
Upon a successful login, LoginRocket redirects the user to your Login Handler URL, automatically adding the new login token: https://myapp.com/login?token=SAMPLE
Your app, at /login, verifies the login token and sets up the user’s session. This can be as little as 10 lines of code. The user is logged in and you’re done.
What if you want to customize this process, say to return the user to a specific page that they need to be logged in to see? It’s not too much different.
User visits protected page and isn’t logged in, so your app redirects them to https://yourapp.e1.loginrocket.com/login?redir=/path/in/app.
LoginRocket displays the login form.
On successful login, LoginRocket redirects them, adding both the login token and the redir param previously sent: https://myapp.com/login?token=SAMPLE&redir=/path/in/app
As before, your app verifies the token and establishes the session. Then it verifies redir and redirects accordingly.
redir is a pass-through value. LoginRocket itself does not use it. However, it does validate that it is a path or path-like value. It cannot be a full URL. If a full URL is provided, it will be simplified down into a path.
Hint: redir doesn’t have to be a valid path in your app. You could send a value like something/12345 that might be intended as more of a key/value pair. As long as your app knows what to do with it, it can parse it and act accordingly.
Let’s go further. What if you have 2 different apps and want to redirect the user between them? In the previous example, redir must be a path only and the user is always redirected to the Login Handler URL.
LoginRocket can also be configured with a list of valid URIs it can redirect to. To do this, add one or more URIs to the Connected App’s Redirect URIs field.
LoginRocket will check the redirect_uri value against each listed value in Redirect URIs to look for a match. A URI is considered matching if it matches in full, anchored left.
| Redirect URIs | redirect_uri |
Matches? |
|---|---|---|
https://myapp.com/ |
https://myapp.com/ |
Yes |
https://myapp.com/ |
http://myapp.com/ |
No (http vs https) |
https://myapp.com/ |
https://myapp.com/path |
Yes (can be longer) |
https://myapp.com/path |
https://myapp.com/ |
No (cannot be shorter) |
https://myapp.com/#/ |
https://myapp.com/#/path |
Yes |
https://myapp.com/#/path |
https://myapp.com/other#/path |
No (matching includes fragments) |
Here’s the flow:
User visits your second app and isn’t logged in, so the app redirects them to https://yourapp.e1.loginrocket.com/login?redirect_uri=https://anotherapp.com/session/new.
LoginRocket displays the login form.
On successful login, LoginRocket redirects to redirect_uri, adding the login token: https://anotherapp.com/session/new?token=SAMPLE
The app verifies the login and sets up the session.
If no valid match for redirect_uri is found, LoginRocket safely defaults to using the Login Handler URL.
Hint: You can combine the last two examples by sending both redirect_uri and redir. So step 3 above might end up looking like https://anotherapp.com/session/new?token=SAMPLE&redir=/path/in/app.
What if you don’t want the user to have to login everytime they come to the login form? In all of the examples above, the user’s prompted to login, whether or not they maybe just did.
LoginRocket handles this too, as part of Seamless SSO. Just go to Realm -> Settings -> LoginRocket -> Seamless SSO and turn it on.
Once enabled, each user’s current login session is remembered. Any time the user reaches the login step (step 2 in the above examples), LoginRocket will check their remembered session to see if the session has expired or has been logged out. If it’s still valid, they will be automatically logged in and redirected, without any interruption.
Your app will still receive a token parameter, so you can (re)establish the session if necessary. This simplifies things for a single app and it’s even more useful for multiple apps as each app receives its own copy of the token and can establish its own session without worrying about shared state between apps (AuthRocket handles sharing everything).
Once a user can login to multiple domains using a single session, the question is how to log them out. This is where AuthRocket’s managed sessions really shine.
In any given app, simply logout the session via the AuthRocket API. The next time the user visits the LoginRocket login page, they will be required to login again since the previous session has now been invalidated.
Inside each app, be sure to regularly validate the session with AuthRocket via the API. This will catch if the session has been invalidated. You can do this on every page load or you can cache it for whatever period of time might be appropriate for your app.
Caching strategies include a fixed period of time (say 5-15 minutes) or using the cache only on read (or other unimportant) actions and always checking on writes or important actions.
Another approach is to cap the session period inside your app to a shorter period of time (say 1 hour), but letting AuthRocket’s max session time (part of the Realm’s settings) be much longer. While this will trigger more frequent logins to LoginRocket, if the session is still valid, LoginRocket will silently log them back into your app, not actually requiring the user to login again.
If you need to ensure LoginRocket prompts for a fresh login, add a reauth=1 parameter: https://yourapp.e1.loginrocket.com/login?reauth=1. Even if there is a remembered session for the user, the user will be prompted to login again.
If you have the session token or ID, it is preferable to use the Delete a Session API call to terminate a session.
However, if you don’t have it for some reason and you want to ensure LoginRocket is logged out, redirect to: https://yourapp.e1.loginrocket.com/logout. LoginRocket will terminate the session if it still remembers it.
Questions? Find a Typo? Get in touch.