Allow folks to specify a resource for sign-in route.

[jimsynz]

It can be confusing that the default sign in page will just show two forms if you have two resources with authentication enabled. So we should add a resources: [Ash.Resource.t] option to sign_in_route.

Same probably goes for reset_route also.

[skanderm]

I'd actually love this for a current project I'm working on. Is there a current workaround for hiding non-desirable resources? I have users with auth and a completely separate set of subscription resources that I use a magic_link to unsubscribe using the token system. My current sign-in page shows both, so any pointers would be welcome.

[jimsynz]

The current workaround is to just role your own liveview for each one - probably just by copypasta'ing the file from this repo.

[Morzaram]

Would also love this without having a work around haha. I would be down to try my hand at making this possible, but I'm not sure the best strategy to do so. Would love any guidance on how we'd want to make it work.

[zachdaniel]

Essentially we'd want to start at the live session level, and take the option and put the value into the live session. Then, when listing authenticated resources we'd check for that option value, and if its not set we'd use the full list. It shouldn't be a significant code change I think.

[Morzaram]

Okay, this makes sense, I think for me I'm wondering about path generation for sign_in_route(). How would we approach differentiating between an 'admin' sign-in page vs a 'member' sign-in page?

Should we have a different method or we can have a sign_in_route that changes the name_path ie:

sign_in_route(for: Member, as: member_sign_in_path, path: "/members")

which will then return:
member_sign_in_path GET /members/sign-in AshAuthentication.Phoenix.SignInLive :sign_in

or we can expand on the auth_routes_for Member, to: MemberAuthController, auth_type: :password

How do you see it working?

I'm quite junior and I want to make sure I take it in the direction you see :)

[zachdaniel]

I'll defer to @jimsynz on that front :D

[jimsynz]

Okay so firstly I think we should consider leaving the existing sign_in_route and reset_route alone so that we can deprecate them once we have a more sensible replacement.

So, given that we can introspect a bunch of useful stuff about the resources and their authentication strategies, what would folks prefer to see in their router? This is one idea I had which may or may not be a better alternative. Give me your ideas.

auth_ui_for Member, include_strategies: :all | [atom], exclude_strategies: :all | [atom], unify: boolean

which could generate routes something like this when unify is false:

member_sign_in_with_password_path GET /members/password/sign-in, AshAuthentication.Phoenix.SignInLive, :password
member_register_with_password_path GET /members/password/register, AshAuthentication.Phoenix.RegisterLive, :password
member_reset_request_path GET /members/password/reset_request, AshAuthentication.Phoenix.ResetRequestLive, :password
member_reset_path GET /members/password/reset/:token, AshAuthentication.Phoenix.ResetLive, :password
member_sign_in_with_google_path GET /members/google/sign-in, AshAuthentication.Phoenix.SignInLive, :google
# etc ...

and when it's true it is more like the current behaviour:

member_sign_in_path GET /members/sign-in, AshAuthentication.Phoenix.SignInLive
member_register_path GET /members/register, AshAuthentication.Password.RegisterLive
member_reset_request_path GET /members/reset_request, AshAuthentication.Phoenix.ResetRequestLive
member_reset_path GET /members/reset/:token, AshAuthentication.Phoenix.ResetLive

Certainly open to lots of feedback as I'd like to solve this once and for all.

[ArthurClemens]

This setup gives flexibility for setting up custom pages.

In my experience we do need to provide for different pages to facilitate way-finding and to accommodate (error and succes) feedback. "Pages" in the conceptual sense - it could be facilitated by multipurpose modules like SignInLive but that would require a more flexible configuration than the current setup.

To facilitate discussion, I've created flow diagrams with the expected "pages".
Note: the hexagonal shapes are pointers to sub flows.

[jimsynz]

I've spent some time thinking about how we might support multi-step flows because currently it's not super easy. For example sometimes folks want unconfirmed users to be able to sign in and reduce their access with policies, and sometimes folks want confirmation to be a gate. This is probably a discussion for https://github.com/team-alembic/ash_authentication rather than here, but worth mentioning. Maybe some kind of rule-based system similar to policies? Not sure.