• Members 153 posts
    March 2, 2023, 9:59 a.m.

    I don't understand this at all. I am fiddling around in the dark trying to find a magic formulae. With other apps (hedgedoc, gitea) I'm just providing the client id and secret, and it just works. So I totally accept there's an absense of understanding on my part.

    What I have, which seems to work closest is setup. It makes the request, is redirected back to misago, but fails with the message "Could not sign in with Authelia, JSON sent by the OAuth2 provider did not contain a user id."

    You are going to ask my why my setting are like that, and I have no idea. I'm completely in the dark.

    user_data.png

    PNG, 80.3 KB, uploaded by tetricky on March 2, 2023.

    retreiving_user_data.png

    PNG, 44.9 KB, uploaded by tetricky on March 2, 2023.

    retreiving_access_token.png

    PNG, 55.3 KB, uploaded by tetricky on March 2, 2023.

    basic_settings.png

    PNG, 59.7 KB, uploaded by tetricky on March 2, 2023.

  • March 2, 2023, 12:23 p.m.

    Good news, missing user ID means everything went great, except the final step (retrieving user data from JSON).

    I am 99% sure Authelia returns user ID under the sub path.

    I am also not sure but user’s name may be username and not name. If your user from Authelia is created with random name instead of correct one, please try that change too.

    There’s a plan to add „debug” option to OAuth2 client, where error message will display OAuth server response, making it easier to debug, but that’s not coming to next release.

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

    I've changed sub username email.

    Progress. That now logs in the authenticated user from authelia (as long as the email address is not consumed by another user), with some major gotcha's.

    1. It will log the user in not mapping either the authelia username or display_name, but rather generating a seemingly random username ( User_XXXX - where XXXX changes with each login)
    2. It seems to map this login to the first superuser. Every time. Consequently this superuse login name changes every time and now requires logging in using authelia (luckily I have another superuser to get access to the settings).

    Ideally I would like to map the authelia username to the misago user, and the authelia display_name to be what is displayed in as the username in misago (this can be changed in authelia, and is the intended behaviour). This may not be possible, but I mention it as an aside (the alternative would be to log in to misago with the authelia username but be able to change the displayed name in misago).

    As another aside, it would be good if misago checked that the user trying to log in is a member of an assigned group - say misago. Some users may be allowed to access some services...but not misago. This should be determined at the auth stage.

    user_mapping.png

    PNG, 62.6 KB, uploaded by tetricky on March 2, 2023.

  • Members 153 posts
    March 2, 2023, 1:52 p.m.

    It seems that the assignment to the admin user is because when attempting to log in a new user, the email address was set the same as the misago registered admin user.

    So.

    If I (legitimately) create a user in my authelia instance, and then update the email address to be that of a misago administrator, the auth login in misago maps that new user to afmin user with the same email address. This is very not good!

    Clearly the mapping should be based on the username. This is authoritative in the auth single source of truth (authelia) and cannot be changed (unlike the email address).

    Logging in as a new username without an email address that has already been consumed, then it correctly assigns a new user...but it does so with the random username as above, rather than username or display_name

  • March 2, 2023, 1:58 p.m.

    Those random names mean that Misago is not finding the name for user. Username path is invalid.

    There's no separate "display name" in Misago that it may display instead of "username", so you would have to decide if Misago should use either username or display name from Authelia.

    Here's Authelia documentation for paths to user name and display name: www.authelia.com/integration/openid-connect/introduction/#profile

    So its either preferred_username for username or name for display name.

    If I (legitimately) create a user in my authelia instance, and then update the email address to be that of a misago administrator, the auth login in misago maps that new user to afmin user with the same email address. This is very not good!

    This is by design. You are delegating verification to identity provider, making it it's job to verify the e-mail addresses.

    This is authoritative in the auth single source of truth (authelia) and cannot be changed (unlike the email address).

    Username is weak as authoritative source of truth, simply because its much more commonly changeable than e-mails are, and comes with less verification than e-mails do. You should setup Authelia to verify user e-mails when they change them.

    To elaborate a little on this, if user signs in to Misago through OAuth 2, Misago pulls their ID from the user JSON and does either:

    • if this ID is associated with existing user account, User is signed to this account
    • if this ID has no existing user account associated with it, it looks up user with e-mail next.
    • If user account with e-mail exists, ID is associated with this user. If not, new user account is created.

    Please note that enabling OAuth 2 disables Misago registration and e-mail change features. So only users with accounts registered before OAuth 2 was enabled will be "effected".

  • Members 153 posts
    March 2, 2023, 2:14 p.m.

    name and preferred_username work exactly as described.

    That's perfect.

    So I can manage my users through authelia. I was going to allow users access to the ldap backend for my users to change usernames and email addresses...but I wont. I will make it on admin request only.

    The only issue that I would consider outstanding for me, is checking that the user is a member of the group that allows registration (rather than any member of the auth mechanism). I appreciate that my problem is not your problem, and I can work around it.

    Presumably at least one superuser needs to be created first, and then this can be mapped to an authenticating user through the auth? Then other users joining with auth can be assigned as administrators/superusers?

  • March 2, 2023, 2:25 p.m.

    This is very specific requirement that I feel should be handled by custom plugins. But plugin system doesn't support this. We have new_registrations_validators hook that is currently called on OAuth2 registrations, but it doesn't get entire JSON with user data. We could have extra oauth2_new_registrations_validators hook that is called with JSON data that would let you look up if user is member of groups you want to let registration and return an error otherwise.

    Yup. Ideally site staff setups their account "classic way", then they enable the OAuth, connect their account to one in provider, then other users join through OAuth and if some of them are admins, their admin permissions on Misago are granted through Misago's admin panel.

  • Members 153 posts
    March 2, 2023, 2:30 p.m.

    Yes. But I don't think it's possible to log into the admin panel anything other than the "classic" way (at least I don't seem to be able to). That means it's not possible to promote an auth user to admin status...but rather they would have to have a 'classic' admin account created....which couldn't have the same email address, or the consumption of the username would be problematic.

    It's messy, but workroundable.

  • March 2, 2023, 2:31 p.m.

    BTW, this is none of my business but it would be awesome if you could write a setup guide for Misago OAuth 2 with Authelia 🙏

  • Members 153 posts
    March 2, 2023, 2:32 p.m.

    I will. Promise.

  • March 2, 2023, 2:37 p.m.

    You need to set Misago password on their accounts that they should then change to their custom one after they sign in. This is limitation to OAuth2 in Misago but I agree it makes sense to support it. It's just that it would take plenty of extra work for something that currently has workaround that I've decided to don't do at the moment.

  • Members 153 posts
    March 2, 2023, 3 p.m.

    That doesn't work. I have tried to do exactly that.

    I was unable to promote a user and log into the admin panel in this way.

    Worse, having set the password (in misago) I now cannot log in as the corresponding authelia user, and have the name recognised (possibly because it has some legacy of the email address somewhere....deleting the account does not fix it).

  • March 2, 2023, 3:06 p.m.

    If account stops working with Authelia after password is set on it, its a bug and I will give it a look for next release.

  • Members 153 posts
    March 2, 2023, 3:23 p.m.

    It's only that account that I have tried to update to an admin account in the way discussed. All other accounts seem to continue working as before, and new (none admin) accounts join correctly.

    This promote to an admin account is the tricky one, and I could do with a working workflow for that.

    ---Edit---

    It seems to be (a fault on my part) that the preferred_username clashed with a name. Resolve that, and it solves the problem. So if I make name, and preferred_username an admin function, then I can avoid the issue.

    I just need a way of checking name (once assigned cannot be changed) and preferred_username (can be changed!) never conflict.

    Presumably the Presumably the @username within misago addresses the current preferred_username of the user (which can change), but not the name which is possibly unknown to other misago users?

    For functionality outside of misago preferred_username can change over time...but this might be problematic for private room ownership/invites etc?

  • March 2, 2023, 3:51 p.m.

    User mentions point to use currently using given name. This is limitation due to text being source of truth for user posts. If posts were, say, JSON emitted by WYSIWYM editor, we could embed extra metadata like user ID in mentions at time those are written by user, making those stable across username changes. But mentions only break when post mentioning user is edited after they changed their name.

    All ownership in Misago is tied to user's ID in Misago database, so user changing name will not change the ownership anything. But other users will need to keep on mind that "Bob2137" is now "Darth_Striker_XX" when searching for user to mention or invite to private thread.

  • Members 153 posts
    March 2, 2023, 4:22 p.m.

    That's all fine. There is a process workflow that makes sense, and can be enforced.

    Also I can confirm that user promotion does work where there isn't a username/name clash. So this is all as per my requirements, and I will work on a writeup.

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

    This is problematic not only in the case where the new user hasn't yet logged in (but changes their email address), but also in the case of where a user has logged in, but then subsequently changed their email address legitimately with the auth provider (authelia/lldap in my case).

    • Imagine a user has an email address, that subsequently changes for unforeseen reasons (this might be a work email, and they move jobs, or an isp provider that the user moves from, or an email provider service that is withdrawn). The point here being that email addresses may, in some cases, be long lasting. But very often they are not.
    • So the user, quite legitimately updates their email address with the auth provider (authelia/lldap).

    • Logging into misago now correctly identifies the previously logged in user, and associates the correct account (from the username), however the email address in misago is retained as the incorrect old email address, and there is no way for the user to change that.

    • Because the user authenticates with an external service there is no way for a misago adminstrator to change the email address (this is quite correct, but means there is no possible resolution to the previous problem).

    In the terms of the authentication provider the name is authoritative and does not change. All other things (email, preferred_name, password) are not authoritative, but their association with the name is managed externally by the auth provider.

    With the current status of misago with external oauth that means than there is a serious problem in the event that any user changes their email address. Which is a highly likely event, that happens regularly.

    I cannot stress enough. The name is authoritative. The email address is not.

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