Skip to content
Snippets Groups Projects

Move login to oauth.

Merged Move login to oauth.
oauth into develop
All threads resolved!
Merged lain requested to merge oauth into develop
All threads resolved!

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

  • lain
    lain @lambadalambda ·
    Author Owner

    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

  • HJ
    HJ @hj ·
    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
  • lain
    lain @lambadalambda ·
    Author Owner

    I think this probably breaks login after registration, though.

  • HJ
    HJ @hj ·
    Maintainer

    I suppose it could do that.

  • HJ
    HJ @hj ·
    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
    • src/lib/persisted_state.js
    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
  • kaniini
    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.

  • kaniini
    kaniini @kaniini ·
    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

  • lain
    lain @lambadalambda ·
    Author Owner

    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.

  • HJ
    HJ @hj ·
    Maintainer

    can we get password form back then?

  • lain
    lain @lambadalambda ·
    Author Owner

    sure, i'll add it in later today with an option to switch between the mechanism

  • lain added 1 commit

    added 1 commit

    Compare with previous version

  • lain added 1 commit

    added 1 commit

    • a04795d7 - Display OAuth login on login form button.

    Compare with previous version

  • lain added 1 commit

    added 1 commit

    • 1de382f0 - Put oauth text into description.

    Compare with previous version

  • lain added 1 commit

    added 1 commit

    • cf581b7d - On logout switch to public timeline.

    Compare with previous version

  • lain added 4 commits

    added 4 commits

    • cf581b7d...2c2c4452 - 3 commits from branch develop
    • 9f64c967 - Merge branch 'develop' of git.pleroma.social:pleroma/pleroma-fe into oauth

    Compare with previous version

  • lain
    lain @lambadalambda ·
    Author Owner

    @hj can you check again?

  • HJ
    HJ @hj ·
    Maintainer

    cannot log it from localhost FE...

  • HJ
    HJ @hj ·
    Maintainer

    ok, that was caused by CORS weirdness, fixed that on my end

  • HJ
    HJ @hj ·
    Maintainer

    looks good to me, though i'd make password/token a user option, not instance preference.

  • HJ resolved all discussions

    resolved all discussions

  • lain
    lain @lambadalambda ·
    Author Owner

    I think it should be a server setting, as some servers will not work with the password flow (usually if the pleroma server itself does not know the username or password, or these are user is created with additional options in the oauth login screen)

  • HJ
    HJ @hj ·
    Maintainer

    Maybe server should tell clients which authorization methods it supports like ['password', 'oauth', 'lolkerberos'] and client can show/hide options depending on that.

    At least in the future.

  • lain
    lain @lambadalambda ·
    Author Owner

    if you're alright with it i'd move that to the future then and merge this as it is?

  • HJ
    HJ @hj ·
    Maintainer

    sure

  • lain merged

    merged

  • lain mentioned in commit 11f8a4f3

    mentioned in commit 11f8a4f3

    • Please register or sign in to reply