• rafalplens
    2 years ago

    Sorry but this is just NOT true.

    The only authoritative part of OAuth2 is subject, which is what Misago follows and respects. Only reason why Misago associates OAuth users with emails is thay system allowing user to change their email that was done right requires user to verify e-mail ownership through link in e-mail message. Making it much more trustful as fall-back identifier than username is. But this only happens when OAuth was enabled after user already registered on a site using built in registration method. How many users like that do you have?

    Misago (and many other systems like Discourse) mangles user names that don’t follow the system requirements. „John Doe” and „John_Doe” are same username because space is not allowed. „Rafał” and „Rafal” are same username because username needs to use latin alphabeth only.

    Name not changing sounds like something specific to your setup. I’ll setup Facebook as my auth provider. Now I have a problem because you can change your name on Facebook no problem. I’ll setup keycloak where name can be changed as often as user wants to. Now I have problem. I’ll integrate with webstore. Now I don’t have username at all, only their e-mail address. I have a problem.

    email address in misago is retained as the incorrect old email address, and there is no way for the user to change that.

    If this is the case, it is a bug in Misago and I’ll fix it.

  • 158 posts
    2 years ago

    My terminology may be incorrect. What is the case is that the one thing that never changes is the auth username (name) All other things can change. email is the current registered email address for that user, which can change (subject to the procedure with the auth provider). preferred_name is the current display name for the user name and can change (and appears to be correctly used by misago. very well).

  • rafalplens
    2 years ago

    I would like to understand how many users you have that registered on Misago before OAuth2 was enabled that have changed their e-mail address in Authelia in the meantime?

    Can you also confirm that user’s e-mail is not updated after they sign in next time from Authelia with changed e-mail? Because I’ve checked the code and it should change:

    4EA9EF9E-948F-4BAD-B951-563F5365B7A6.jpeg

    I’ve looked at tests suite and there are tests for scenario where user e-mail changed in OAuth2 and was updated in Misago on their next login.

    So if e-mail is not updating in Misago its got to be a bug but I will need examples of okd and new e-mail addresses to test this locally.

    4EA9EF9E-948F-4BAD-B951-563F5365B7A6.jpeg

    JPG, 271.5 KB, uploaded by rafalp 2 years ago.

  • 158 posts
    2 years ago

    Right. I've checked this, and I am now getting a correct behaviour (logging in with name returns updated preferred_name and email). I do not understand what I was previously seeing. I cannot now duplicate what I was previously wrong (and nothing has changed with either misago or authelia). I must have done something stupid. Apologies for that.

    Currently I'm working on a test instance. I have three misago created user profiles (all superusers), and three oauth created user profiles (which I have now tested changing priviledges, etc).

    Accepting that compliant email behaviour is the responsibility of the auth provider, I think misago is actually working as it should. I'm very sorry for making noise over smoke, when there appears to be no actual fire. My only excuse would be that testing across multiple browsers and users gets a bit complicated.

  • rafalplens
    2 years ago

    It's okay. You saw something weird going on and wanted to get down to the cause. I'm just happy it worked out in the end 😀

  • 158 posts
    2 years ago

    Your constructive attention is appreciated.

    I have a problem to resolve with a work issue, then I will look at integration with authelia documentation. Where would you like that posted, here as a thread? (I shall also endeavour to get it added to the authelia docs).

  • rafalplens
    2 years ago

    Posting it as a thread titled like "Authelia OAuath 2 guide" in integrations category is best IMHO.

  • 158 posts
    2 years ago

    I removed 'groups' from the scopes in my authelia client id definition. Having done so, misago then stopped working with authelia.

    I know that groups are not used in misago, but are they required nevertheless? I actually don't mind if they are...they might be used one day, which would be good. I just need to know from a documentation point of view.

  • rafalplens
    2 years ago

    It would help if you provided more context than "stopped working". What error message is Misago now displaying?

    I don't see groups claim exposing anything that Misago would need. It only requires id, name and email. Maybe there's missing space in claims setting now?

  • 158 posts
    2 years ago

    If I remove 'groups' from scopes I get:

    If I replace groups it works.

    (as an example, gitea works without 'groups' in the scopes)

  • rafalplens
    2 years ago

    Can you show screenshot of your scopes setting? Both working one and one without groups that's not working?

  • 158 posts
    2 years ago

    What you said triggered me to think.

    I had removed groups from scopes in my authelia config...but I had forgotten that part of the misago oauth config was to include the required scopes - and I hadn't removed 'groups' from the misago config.

    When I did, it all worked fine without groups.

    I just needed to remove it from the config of both, not only authelia.

    I'm making a lot of stupid mistakes on this.

  • jamesdelliottpanorama_fish_eye
    4 posts
    2 years ago

    Sorry I am generally too busy to follow all of the different sites, pinging me on Discord, GitHub, Matrix, or email is the best way to get in contact. I try to stay present in many social networks but it's hard to be across everything.

    Authelia respects the spec and the sub / "subject" claim is the authoritative unique opaque value that represents an individual user. We could use their username technically however for privacy reasons we expressly hide that behind the profile scope and also support pairwise subject identifiers. However this is for the time being directly linked to the preferred_username in the backend (which is actually the username value just we map this to the appropriate standard claim).

  • rafalplens
    2 years ago

    There's new oauth2_validators hook coming in Misago 0.30 that will let you create a plugin that will raise a validation error based on raw user JSON returned from Authelia.

    Relevant PR: github.com/rafalp/Misago/pull/1473

  • jamesdelliottpanorama_fish_eye
    4 posts
    2 years ago
  • 158 posts
    2 years ago

    Nope. Very much thanks to @rafalp and @jamesdelliott - all your your work fellas. I just did a small component of the admin.

  • rafalplens
    2 years ago

    Thank you both. It was your effort that made this possible :D

    For the record, I've removed option for using GET to retrieve the access token in Misago 0.30, so we are on good side now.

Search
  • Enter search query (at least 3 characters).

Your options