Discourse SSO updates

[MatthewL246]

Resolves #345 and #352

Changes

This adds new features to the Discourse SSO that will sync a user's groups based on their PNID's access level, Stripe tier, and linked Discord account's roles in the server. The access levels, tier levels, role IDs, and group names are all controlled by values in the config file for easy modification.

This also adds a new feature to manually sync a user's SSO state without requiring them to sign out and back in. It is currently used after handling a Stripe event, and it could be used in the future when a user is promoted/demoted as a moderator/developer. This would address the concerns shared in #345 over a user purposefully staying signed in to avoid being removed from a privileged group. For now, I think using this after handling a Stripe event and having a forum admin manually remove a user's groups when they are demoted will work fine, considering how rarely the second event happens.

Setting up the manual sync feature will require creating a Discourse API key. I would suggest setting its user to system, permissions to granular, and only enabling the sync SSO route for security reasons.

Prerequisites

This requires PretendoNetwork/account#128 to be merged first.

Current issues

As I commented in createDiscoursePayload, I noticed some issues with primary groups while testing this. I wouldn't consider them showstoppers because this basically only affects developers and moderators, none of a user's groups will change during most logins, and users can select their own primary group in their profile settings.

Testing

I tested this as thoroughly as I could using self-hosted instances of the website (set up with a real Discord application and bot) and Discourse. The only issue is the Stripe integration, as I don't have a Stripe account. I tested the Stripe tiers functionality by creating fake Stripe tiers in the database under the assumption that they are just regular integers. I also manually tested the discourseUserExists and syncDiscourseSso functions used in the Stripe event handling by using the debug console. However, adding the SSO syncing to the end of 'handleStripeEvent` is a bit of an assumption and should be reviewed.

• I have read and agreed to the Code of Conduct.
• I have read and complied with the contributing guidelines.
• What I'm implementing was an approved issue.
• I have tested most of my changes.

[CLAassistant]

All committers have signed the CLA.

[MatthewL246]

I hope you consider rewording this message to specify that this CLA is the Developer Certificate of Origin. My initial reaction to this notification was negative because I worried that this was one of those CLAs corporations use to give the project owners special rights over others' contributions.

…

On Wednesday, Feb 5, 2025, 2:06 PM, wrote: [](https://cla-assistant.io/PretendoNetwork/website?pullRequest=363) <br>Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our [Contributor License Agreement](https://cla-assistant.io/PretendoNetwork/website?pullRequest=363) before we can accept your contribution.<br>_{You have signed the CLA already but the status is still pending? Let us [recheck](https://cla-assistant.io/check/PretendoNetwork/website?pullRequest=363) it.} -- Reply to this email directly or view it on GitHub: #363 (comment) You are receiving this because you authored the thread. Message ID:

[binaryoverload]

I hope you consider rewording this message to specify that this CLA is the Developer Certificate of Origin. My initial reaction to this notification was negative because I worried that this was one of those CLAs corporations use to give the project owners special rights over others' contributions.

I hear your thoughts - and I agree the phrasing lends itself to worry people. Unfortunately, it's not something the CLA bot allows us to configure - so we'll just have to rely on people clicking on the CLA and seeing that it's just the certificate of origin