• March 3, 2023, 12:43 p.m.

    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.

  • Members 153 posts
    March 3, 2023, 12:52 p.m.

    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).

  • March 3, 2023, 1 p.m.

    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 on March 3, 2023.

  • Members 153 posts
    March 3, 2023, 1:21 p.m.

    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.

  • March 3, 2023, 1:33 p.m.

    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 😀

  • Members 153 posts
    March 3, 2023, 1:40 p.m.

    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).

  • March 3, 2023, 1:47 p.m.

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

  • Members 153 posts
    March 3, 2023, 4:15 p.m.

    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.

  • March 3, 2023, 4:40 p.m.

    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?

  • Members 153 posts
    March 3, 2023, 4:51 p.m.

    If I remove 'groups' from scopes I get:

    If I replace groups it works.

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

  • March 3, 2023, 4:57 p.m.

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

  • Members 153 posts
    March 3, 2023, 5:20 p.m.

    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.

  • Members 4 posts
    March 9, 2023, 5:05 a.m.

    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).

  • March 12, 2023, 2:13 a.m.

    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

  • Members 153 posts
    March 19, 2023, 9:23 a.m.

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

  • March 24, 2023, 8:59 p.m.

    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.