Feat: Add (overridable) support for page titles

[frankdugan3]

It would be great to add page titles to the authentication routes, e.g.

|> assign(:page_title, "Log In")

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.

[zachdaniel]

Sounds good to me :D

[jimsynz]

[ArthurClemens]

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.

[zachdaniel]

What is RevertLive?

[ArthurClemens]

Typo, should be ResetLive

[zachdaniel]

Yeah I'm not sure what that page is for. Maybe an artifact? @jimsynz

[BryanJBryce]

@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:

[BryanJBryce]

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

[ArthurClemens]

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.

"Pages"

• Sign in page
• Registration page
  • Confirmation page
• Reset password flow:
  • Request page
  • Request sent confirmation page
  • Instructions email
  • Change password page
  • Password changed confirmation page
  • Change password error page (e.g. link expired, time limit reached)

Common page elements

These will likely differ per page, which means that ideally each of the pages above should be supported by configurable options.

• page_title for html head (string)
• before the form:
  • image (url)
    • hide image (boolean)
  • heading (string)
  • info text (string)
• form:
  • field labels and hints (strings)
  • error messages (strings)
  • submit button (string)
• after the form:
  • optional elements such as help text, links

[jimsynz]

There is relevant discussion in #236 you may want to share some of this there.