stonith404
feat(auth): auto redirect to OAuth provider
Make it possible to disable signing in with password and add automatically redirect users to OAuth provider.
close #329
It's confusing that the allow-registration is in the share category, so I add a allow-registration config in the new account category, but I haven't migrated the old config to this.
Should I do the migration or leave it in share category?
@zz5840 Yeah I think it would make sense to migrate it to the new account category.
You first have to create a migration with npx prisma migrate dev and then manually add the migration logic to it. If you need help with the migration let me know :)
Hello !
I would love this feature, any visibility on when it will be merged ?
Thanks for all the work !
@thelouisvivier Hi, it still needs some trivial work, but I'm a bit busy lately. I'll work on it ASAP.
@thelouisvivier Oh thanks, it seems all that's left is the database migration, I think I can make it works this weekend.
But there's a small trouble, if home page is disabled and auto redirection to oauth provider is enabled, a user will be redirect to provider's auth page immediately when he sign out. And for some providers, confirm is omitted for users that have logged in the app before, which will cause a user can not log out the app forever. Any ideas on this?
@zz5840 Yes, I am using Microsoft Oauth, and I don't have any confirmation for login.
What I was thinking for that was :
-
an admin toggle to disable builtin auth and the associated form.
-
keep the sign in page but with only the oauth button(s).
This way, users can only login through oauth, but you don't have the issue of the direct redirect you're talking about.
And the advantage of that is you can have multiple oauth providers at the same time and still be able to deactivate local accounts.
In addition, it would be nice if instead of only displaying the icon of the oauth provider, we would be able to add a name next to the icon on the login page.
Find attached a visual exemple.
What do you think ?
@thelouisvivier You are right, and I have implemented what you proposed. But auto redirection to IdP is also a significant feature, right?
@zz5840 well, from my point of view no. When SSO is implemented on a platform, in general, it seems that you always have a sign-in button then a redirect to the IdP. It's also required if you have multiple Oauth provider.
If you don't have that sign-in button, users can be quite lost. And you will have issues like the one described above. For example, Microsoft SSO doesn't display any sign-in confirmation if you are already logged in with your Microsoft Account.
The best of both worlds would be an option for an auto redirect. But I don't know if it's not too much work for a specific use case.
What do you think ?
@thelouisvivier The option for auto-redirection is also implemented, so should we ignore this problem and just leave a warning to admin?
@zz5840 I think it's the best you cans do yes. A warning next to the parameter and in the documentation. 👍
Hey @zz5840 ! Happy new year ! Did you find time to achieve the functionality ?
If you need help for testing, let me know !
@thelouisvivier Oh, maybe this weekend. You can pull and run it if you want to test.
Hey @zz5840 Just tested a bit this version.
I spotted a bug : the option "Allow registration" is present on "Account" config page, but also on "Share" config page. And the one really working to disable/enable the registration is the one in the "Share" config page.
Also, I don't understand the purpose of the "Allow registration" option in the Social Login page :
I couldn't test the authentication flow on my test environment because I don't have Oauth configured on it.
Otherwise, it seems very promising !
I was just thinking, could we also allow password authentication but just for the admin ? This way, if the OAuth is not working, an admin can still access the configuration pages and fix any issues ?
@thelouisvivier Previously, the "Allow registration" option is on Share page, and I'm working on migration it from "Share" to "Account" page. The "Allow registration" option on Social Login page is used to control whether new user can be registered via OAuth login flow. These are to different options.
I was just thinking, could we also allow password authentication but just for the admin ? This way, if the OAuth is not working, an admin can still access the configuration pages and fix any issues ?
It's an interesting idea, but I don't have much time to work on it.
this is how Immich implemented this. Love your app btw :-)
Auto Launch When Auto Launch is enabled, the login page will automatically redirect the user to the OAuth authorization url, to login with OAuth. To access the login screen again, use the browser's back button, or navigate directly to /auth/login?autoLaunch=0.
@mobiledude oh great, that's good to know. I will wait on final implementation then ! Thanks
Any update on this or help needed? This is a feature I would really like, and am happy to contribute or help test anything.
When Auto Launch is enabled, the login page will automatically redirect the user to the OAuth authorization url, to login with OAuth. To access the login screen again, use the browser's back button, or navigate directly to /auth/login?autoLaunch=0.
This seems like a good approach.
Thank you all, I think I should take some time to deal with this PR recently.
---Original--- From: "Matt @.> Date: Thu, Jul 11, 2024 14:40 PM To: @.>; Cc: "Qing @.@.>; Subject: Re: [stonith404/pingvin-share] feat(auth): auto redirect to OAuthprovider (PR #343)
Any update on this or help needed? This is a feature I would really like, and am happy to contribute or help test anything.
When Auto Launch is enabled, the login page will automatically redirect the user to the OAuth authorization url, to login with OAuth. To access the login screen again, use the browser's back button, or navigate directly to /auth/login?autoLaunch=0.
This seems like a good approach.
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>
Do you still plan to work on this PR or should I close it?
@stonith404 Sorry for late response, I'll close it now.