Skip to content
Snippets Groups Projects

Move login to oauth.

Merged lain requested to merge oauth into develop

This unifies Mastodon and Pleroma logins and makes it easier to implement SSO schemes.

Merge request reports

Loading
Loading

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
  • HJ
  • HJ
  • lain added 1 commit

    added 1 commit

    Compare with previous version

  • I moved the state persistence stuff around a bit so that the state will be completely loaded before the app is initialized, so we won't have those late-loading issues anymore.

  • lain added 6 commits

    added 6 commits

    Compare with previous version

  • Maintainer

    Except for replacing login form with a button it...

    image

    At the very least I'd keep both methods for now, this feels like a downgrade, UX-wise.

    Edited by HJ
  • I think this probably breaks login after registration, though.

  • Maintainer

    I suppose it could do that.

  • Maintainer

    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.

  • kaniini
    kaniini @kaniini started a thread on commit 9af204b2
  • 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)) {
  • kaniini
  • kaniini
  • Contributor

    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.

  • Contributor

    (another commonly discussed usecase for this OAuth SSO stuff is enabling setups like pawoo, where you log into your pixiv account to gain access. this is asked about from time to time.)

  • lain added 2 commits

    added 2 commits

    • b6cd4ff3 - Fix typo.
    • 4d9680e7 - Re-activate registration, use oauth password flow to fetch token.

    Compare with previous version

  • lain added 1 commit

    added 1 commit

    Compare with previous version

  • This reactivates registration, which will then use the password flow to get a token and log you in immediately. With SSO schemes we can't do registration, so it won't matter that the password flow doesn't support SSO.

  • Maintainer

    can we get password form back then?

  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Please register or sign in to reply
    Loading