deathandmayhem / jolly-roger

Dead men tell no tales!
MIT License
19 stars 5 forks source link

Migrate external integration configuration from global to per-hunt #630

Open ebroder opened 2 years ago

ebroder commented 2 years ago

Right now, external integration configurations are global. If we allow anyone to create a hunt (or even if we expanded hunt edit permissions from admins to operators), this creates a confused deputy risk. Jolly Roger is (e.g.) an admin on the servers it inhabits, which is quite a lot of role-assignment power.

The best way to handle this is to make external integrations a property of the individual hunt. This is most pressing for Discord, and secondarily pressing for mailing list integration (though #495 may have some bearing here).

I'll copy what @zarvox said when I originally proposed this as part of #618:

We could also take this opportunity and overall goal as an opportunity to rethink the nature of how some of our external integrations are configured. For instance, instead of having server-global settings for doc templates, Drive folder and server account, we could have an approach where when configuring a hunt, the hunt-creating operator configures credentials for the backend to use for that hunt. Then, instead of having a single gdrive client refresher, we'd have one-per-hunt, and all serverside actions on drive would need to look up the hunt and use the credentials from that Hunt. This would definitely increase the surface area of credentials that we'd need to store and retrieve, and perhaps we'd want to store these values separately from the actual Hunt objects themselves to ensure we don't accidentally publish them to clients, but I see no fundamental reason why we couldn't take this alternate approach, and in our case we could continue to use our current google account in production as the "data owner" that provides the Drive folder and the ability to create documents within that folder to the hunt config. Splitting out the server-wide "identity/code owner" from the per-hunt "data/access owner" feels appropriate.

Discord guild configuration feels somewhat similar. I could imagine an additional step in the Hunt-provisioning flow where the user creating the Hunt would create an OAuth delegation to the bot (probably for a smaller set of permissions than admin, as you've noted), and then the UI for hunt configuration could allow you to select from among [no guild, the guild currently configured, the list of guilds that your user account has granted the bot access]. There will be implications on the backend around DiscordCache data and its visibility; I think based on the structure of Discord's bot integrations we'd still need only one bot account & connection to Discord itself, but we'd have to be much more careful about what data we publish where.

As for mailinglists: I think in practice, besides our current production instance, there are 0 deployments that make use of the blanche mailinglist integration, and if we're being honest, probably close to 0 potential future jolly-roger server administrators who would pick blanche for new future use? The plan for making it so only an admin can add that integration seems adequate to me. I would not be sad if we eventually retired the blanche integration in favor of some other mailinglist integration (though I'm also not excited about writing a new one and migrating all our users either, and we definitely need a mailinglist for our team somewhere, and I'm not excited about requiring Google accounts for participants, but I'm also not excited about "run your own mailinglist software" so I don't have a great alternative).

That said, my intuition is that we shouldn't require people to mint their own OAuth credentials for Google and Discord just to run their own hunts - they're relatively high effort to setup (and, e.g., a bot account is fundamentally tied to a Discord application). Reusing the Google and Discord OAuth clients is definitely more work to manage the permissions right, but I think that's the way to go if we want to make this smooth for folks.

zarvox commented 2 years ago

Yeah I think we envisioned the same thing re: OAuth: -- the server admin configures the OAuth client id/client secret once, and then the creator of each Hunt grants that application access to some resource from e.g. their Google account (granting Drive access to a folder they own) or Discord account (granting the bot permissions to a guild they control).

You mention Discord as high-priority, but I'd personally rank Google Drive even higher here -- it's essential to the jolly-roger experience in a way that Discord is not, and if we were to someday operate a general-purpose jolly-roger instance for the public, I think it's very much preferable that:

  1. storage be accounted to the hunt owner rather than necessarily the server admin's user account, and
  2. any problematic content placed in the drive/documents be the responsibility of the hunt owner rather than the site operator, since the hunt owner is expected to have more of a direct relationship with the participants than the server operator.
ebroder commented 2 years ago

Yeah OK I can agree with that. I will call out that I think that makes the "root folder" setting way more critical, probably required - the flow should probably involve the Google Picker API