Return to the URL of the page the user was in after signing in

[iaincollins]

Instead of just directing to the profile page, we want to save the URL of the current page in a callback URL so that after a user is bounced to an oAuth service (or clicks a link in email) they are directed back to the page they were on after being signed in.

A good way to do this would be to create a route like /auth/callback which loads the session into the client before doing a redirection.

We'd want to do something like Base 64 encode the current URL as a param and preserve any query string parameters.

[iaincollins]

For now, I've migrated the redirect logic into the existing /auth/signin page and simplified the flow by having the logic handled entirely in the sign in page, with no server side routes, making it much easier to change the behaviour in future.

The next step is to create /auth/callback, which should - if the user is logged in - display 'You are being redirected to X' hyperlink (as a fall back for non-JavaScript clients) and (if JavaScript is enabled) update the client side session state immediately and then use Router.push() so that the client is automatically redirected. If the user is not logged in, it should just link (and automatically redirect) to /auth/signin.

All sign in pages (oauth, email) which currently point to /auth/signin should then be updated to point to /auth/callback and the logic in /auth/signincan be simplified.

Once this is done, we can update the logic so the current path is saved either in the callback URL or in a cookie (we don't want to use localStorage as it's not accessible with 'private browsing' enabled) and then /auth/callback can be updated to use that value if it is present.

[iaincollins]

I've now added a /auth/callback route and updated all routing rules to send the client there for final routing after signing in (either via oAuth or email), so there is a single home for all the post-sign in routing logic.

[iaincollins]

This is now resolved in release 3.5.1.

Users are now sent back to the page they were on once they sign in.

This is done by setting cookie so it works for all providers - including oAuth providers that don’t let you pass URL params and over email, without needing to pass the URL the original email (encrypted or otherwise) and also so it works for clients in private browsing mode (where you can't use localStorage).

Logic in the account page sets the redirect value to /account so that when linking/unlinking oAuth accounts users are sent back to the account page after linking/unlinking.

The behaviour for non-JavaScript clients is somewhat basic. They can still login but are not currently redirected back to the page they came from. It’s probably not worth the additional work to support this specific feature for users without JavaScript enabled (the site otherwise forks fine for them though - they can still sign in and out and view and update their profile).

Note also that many oAuth service - including Facebook and Google+ - require JavaScript to be enabled to sign in or to link accounts. This is a limitation of those services and there is no workaround for that.