Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider providing different redirect pages for login and signup #2277

Open
sodic opened this issue Sep 11, 2024 · 4 comments
Open

Consider providing different redirect pages for login and signup #2277

sodic opened this issue Sep 11, 2024 · 4 comments
Labels

Comments

@sodic
Copy link
Contributor

sodic commented Sep 11, 2024

Wasp exposes the onAuthSucceededRedirectTo field that tels Wasp where to send the user after successful authentication (login and signup).

Every now and then, users want different behavior depending on whether the user authenticated through login or through signing up.

For example (source):

[User] wants to redirect the user to the home page if they land on /login while logged in. Our hook only covers the redirect after submitting the login form (you can still land on the login page even when logged in).

Another example (source):

I want to redirect new users who have signed up to a payments/pricing page so they can pay. How can I do this?

I believe users can currently (as of 0.14.2) do this by:

  1. Creating a page for onAuthSucceededRedirectTo.
  2. Saving a special flag on the User entity in the databases.
  3. Using that flag on the onAuthSucceededRedirectTo page to perform custom logic, and updating its state through an action.

But that's pretty ugly.
So, let's consider supporting different redirects based on the operation (login or signup).

@Martinsos Please elaborate on the idea you had here, I'm not what you meant: https://discord.com/channels/686873244791210014/1263461365872595054/1264940497961619527

@sodic sodic added the auth label Sep 11, 2024
@Martinsos
Copy link
Member

@Martinsos Please elaborate on the idea you had here, I'm not what you meant: https://discord.com/channels/686873244791210014/1263461365872595054/1264940497961619527

What I meant here was that I am not sure if having Wasp redirect user somewhere else upon their landing on login page if they are already logged in is ok, seemed possibly too aggressive, and I suggested we instead let them modify the LoginPage itself to handle this if needed.

There are some connected issues here: #1772 and #402 . There is also the matter of login and signup hooks, and how they play into this.

What we will likely want to do is take a holistic view at this, write down all the use cases / requirements, and then figure out the minimal feature set we can offer that will solve them all.

As a very rough first try, requirements / use cases are:

  1. If logged in user lands on /login page, we might want them to be redirected somewhere. I do think this is a bit prescriptive though, I might want my user to be able to visit login page.
  2. We want to redirect them upon successful login and/or signup. But we want those redirect to not neccessarily be the same, and also to posisbly be dynamic.
  3. We want to offer easy support for redirecting user, after login/singup, to whatever page they initially wanted to visited but were redirected to login/signup since it was protected.
  4. Something else?

And tools we have at our disposal are:

  1. Login and signup Auth hooks.
  2. Wasp top level hooks like onAuthSucceededRedirectTo.
  3. Users can implement their own Login / Signup page (likely will).

This might not be all, but I wanted to get the discussion started in this direction.

@infomiho might have the most to say here.

@hellwaiver
Copy link

Agreed. People want to be able to redirect users when they first sign up.

@infomiho
Copy link
Contributor

@Martinsos I think users are able to do almost everything already. Let me elaborate on how I would implement each bit:

If logged in user lands on /login page, we might want them to be redirected somewhere. I do think this is a bit prescriptive though, I might want my user to be able to visit login page.

Users are implementing the login page themselves. They render our <LoginForm> but the pages is theirs. I have successfully used the useAuth + <Redirect /> from react-router-dom to redirect to somewhere if the user is logged in.

We want to redirect them upon successful login and/or signup. But we want those redirect to not neccessarily be the same, and also to posisbly be dynamic.

Users can redirect to a specific page that can decide where they want to redirect the user. The trick is to either use some sort of a field in the DB on the user that's called isOnboardingCompleted or more simply isFirstLoginCompleted or use some sort of local state to remember which route came before (React Router 6 has the concept of route state, so we are not reinventing the wheel!). Then, based on that state, redirect where you want to redirect.

We want to offer easy support for redirecting user, after login/singup, to whatever page they initially wanted to visited but were redirected to login/signup since it was protected.

This is something we need to add extra support for. We need to remember the page that was visited before we redirect to /login. This can also be done with route state .

Basically, what I wanted to say: users own their login and signup pages and they have access to client side state / user object with some properties. It's possible to go quite far with the available tools i.e. useAuth hook and react-router-dom APIs.

@Martinsos
Copy link
Member

@Martinsos I think users are able to do almost everything already. Let me elaborate on how I would implement each bit:

Makes sense, but:

  1. Redirect upon landing on /login page -> I agree, this is fine, they can and should do this on their own.
  2. Redirect upon successful login or signup that is specific for login or signup and also dynamic: ok, they can do it, but it sounds hacky/dirty (field in the db), doesn't it? Seems to me like we could offer cleaner support for this?
  3. Smart redirect back to initially requested page after successful auth: ok, you said we need to add support for this, that makes sense.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants