erikras / erikras/react-redux-universal-hot-example
How to redirect to requested URL after authorization - and with SSR?
- Dominant language
- JavaScript
- Stars
- 12.1k
- Forks
- 2.5k
- PR merge metrics
- No merged PRs in 30d
Description
I'm trying to solve the problem of redirecting the user to their originally requested URL for pages that require authorization.
Right now in this repo, we always just redirect to /loginSuccess
react-router has a great way of doing this, per [this answer on SO](https://stackoverflow.com/questions/33794230/how-to-use-react-routers-redirect-function) which is to use replaceState and set nextPathname.
I have a working implementation of that [here](https://github.com/glennr/react-redux-universal-hot-example/commit/908f209793745d00d752b9f6a6f3d52ac13c9a7a) (no PR yet). However it doesn't work with Server-Side Rendering.
On the server-side, [we do a hard redirect](https://github.com/erikras/react-redux-universal-hot-example/blob/master/src/server.js#L78) (i.e a 302) if we detect that the router wants to change the route. This discards our router.location.state.nextPathname state.
I'm not sure what the best way to preserve that state is. The next best solution I could find is to store that state as a query parameter e.g. /login?next=/original/url - an example of which I've made in [this commit](https://github.com/glennr/react-redux-universal-hot-example/commit/c837df517aa4fb19596b8af2b9ff909087b96ebb).
My question is, is this the correct way of doing it, or is there some secret sauce I'm missing?
Contributor guide
Research direction
Start with src/server.js at line 78 and compare the two linked commits to trace how the requested URL is represented before and after the server-side redirect. Check the authorization and login flow, then establish a redirect that survives SSR and returns the authorized user to the original URL without losing routing state.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- express, javascript, react
- Domain
- authentication, full-stack
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100