Auth Route Design Discussion
Unanswered
alfonsüs ardani posted this in #help-forum
whats stopping me from cramming all auth logic and ui inside an SSR route instead of redirecting to /register or /sign-in?
Case A:
user access /protected-route
user is not logged in, show <SignInPage />
user is then logged in but not registered, show <RegisterPage />
user is logged in and registered, proceed to <ProtectedPage />
Case B:
user access /protected-route
user is not logged in, redirect to /sign-in?next=/protected-route
user is then logged in but not registered, redirect to /register?next=/protected-route
user is logged in registered, proceed to /protected-route
Case A:
user access /protected-route
user is not logged in, show <SignInPage />
user is then logged in but not registered, show <RegisterPage />
user is logged in and registered, proceed to <ProtectedPage />
Case B:
user access /protected-route
user is not logged in, redirect to /sign-in?next=/protected-route
user is then logged in but not registered, redirect to /register?next=/protected-route
user is logged in registered, proceed to /protected-route
32 Replies
Case b
why
It can be redirected after login any page
so does case A
not good
why
if user refresh the page, then what can you do?
again user will go to the protect router and get login page
not good
Also in this case, you can control easily using middleware
@Jerico Aragon if user refresh the page, then what can you do?
depends. is the user logged in? is the user registered?
the same conditional will trigger and the correct component will be shown
i think thats irrelevant
because middleware is just the method to implement case A and case B
the question still stands if i used middleware
@Jerico Aragon again user will go to the protect router and get login page
the user is logged in and registered therefore it will render <ProtectedPage />
case A?
what about case A?
I asked you about this.
what was your question again?
Seems, you have already known about that.
This is help forum
You can create topic
See you in topic
im still having trouble if i should do case A or case B
because on one hand its easier to set up case A but i just thought if there is any pitfalls that i need to know
@alfonsüs ardani whats stopping me from cramming all auth logic and ui inside an SSR route instead of redirecting to /register or /sign-in?
Case A:
user access /protected-route
user is not logged in, show <SignInPage />
user is then logged in but not registered, show <RegisterPage />
user is logged in and registered, proceed to <ProtectedPage />
Case B:
user access /protected-route
user is not logged in, redirect to /sign-in?next=/protected-route
user is then logged in but not registered, redirect to /register?next=/protected-route
user is logged in registered, proceed to /protected-route
American Sable
Case A works but might be become messy if your app grows. Case B would be the better long term choice imo
I also see most websites use Case B
interesting