Move login to oauth.
This unifies Mastodon and Pleroma logins and makes it easier to implement SSO schemes.
Merge request reports
Activity
added 6 commits
-
0aa5fe9d...2f11ec29 - 5 commits from branch
develop - fbe30b49 - Merge remote-tracking branch 'origin/develop' into oauth
-
0aa5fe9d...2f11ec29 - 5 commits from branch
Except for replacing login form with a button it...
At the very least I'd keep both methods for now, this feels like a downgrade, UX-wise.
Edited by HJ-
I think I'll test it around a bit soon enough to see how broken it becomes.
We could always merge it as-is and fix it afterwards, but I don't see it as an improvement that much. SSO only somewhat matters to those who jump to and fro masto/pleromafe, and they usually do that because something is missing from FE, so i guess it's mostly for mastofe users.
Having it external simplifies development process but it really should be internal for UX reasons (it's simply more neat this way and doesn't break the state/flow), as well having it external could lead to losing opened conversation (like, trying to access the DM thread directly by URL gives you an error)
In my opinion we should either add oauth with password login form or keep old login form, with external oauth being a backup, just so if we add 2fa users opted-in to it can use external form for that until pleroma-fe adds that.
73 76 loaded = true 74 77 } catch (e) { 75 78 console.log("Couldn't load state") 76 79 loaded = true 77 80 } 78 }) 79 80 subscriber(store)((mutation, state) => { 81 try { 82 if (saveImmedeatelyActions.includes(mutation.type)) { 83 setState(key, reducer(state, paths), storage) 84 .then(success => { 85 if (typeof success !== 'undefined') { 81 subscriber(store)((mutation, state) => { 82 try { 83 if (saveImmedeatelyActions.includes(mutation.type)) { -
SSO in this case is handling scenarios where Pleroma BE brokers an authentication with a third party service (IndieAuth or perhaps some organizational SSO system like active directory). In those cases Pleroma BE isn't managing the 2FA flow, hince why the redirect-based flow is needed.
Overall I agree that such a use case is non-typical so perhaps we can default to password flow.
Either way, serious +1 for killing http basic auth.
added 2 commits
