Open frankdugan3 opened 1 year ago
Sounds good to me :D
I've been looking into this. It appears that RevertLive ResetLive
is not being used, and that all forms are created inside SignInLive
.
Implementing page_title
for sign_in_route
is straightforward, but for reset_route
something additional is needed that I can't figure out at the moment.
The setup also leads to the 'text' attribute being reused on all authentication pages, so it is not suitable for use as a heading that differs on each page.
What is RevertLive
?
Typo, should be ResetLive
Yeah I'm not sure what that page is for. Maybe an artifact? @jimsynz
@zachdaniel @ArthurClemens It's the page that a user arrives on when they click the password reset link (in their email, for example) route is: /password-reset/:token
:
SignInLive
is a little confusing at first because it can lead you to think it's only for sign in, but it basically hosts any authentication strategy you configure in the user authentication configuration. I'd vote for a name change to AuthLive
or something #namingishard
I figured so much after spending some time on SignInLive.
The problem I see is that the configuration options don't allow for different headings, info texts and page_title for the scenarios "sign in", "register", "reset password", where sign in and register can have variants for email/password and oauth.
Using (misusing?) the Banner
config text
to render a heading leads to the same heading on all pages. This makes it hard to guide the user ("where am I?") or to incentivise to register ("You’re one click away from xyz").
It is also common to have the registration page readable by search engines, so that sign up is just one click away from search results.
There will be other wishes for with pages, and at some point it makes sense to create custom templates, but I think that ash_authentication can do more in bridging that gap.
I've created a list of elements that I think make sense (based on UX work I did on a previous project) - and I'm sure I am missing a few due to the many configurable options.
These will likely differ per page, which means that ideally each of the pages above should be supported by configurable options.
There is relevant discussion in #236 you may want to share some of this there.
It would be great to add page titles to the authentication routes, e.g.
Ideally, these would be configurable via the override system.
If this sounds like a good idea, I'd be willing to work up a PR implementing it.