search

PostHog / plugin-server

Service to process and save PostHog events, supporting JS/TS plugins at that
https://posthog.com
8 stars 5 forks source link

Add API extension #519

Closed yakkomajuri closed 3 years ago

yakkomajuri commented 3 years ago

Changes

This allows plugin devs to access the PostHog API with a lot more ease and security than right now.

This is now possible, for example:

await posthog.api.get('/api/event')

Currently, devs have to do all the fetch requests themselves, meaning they also need to ask the user for a Personal API Key. We have a frontend mechanism to automatically provision one if you name your config option posthogApiKey, but this really isn't great.

Not only that, but after https://github.com/PostHog/posthog/pull/5044, devs now should also specify a project to ensure they're accessing the right data. The token for this could be pulled from events, but what about plugins that only use e.g. runEveryMinute and access API, like the GitHub, GitLab, and Bitbucket annotators?

I originally set out to just build a simple way for devs to access the project token, but then I figured there's a lot more help we can give them here.

Admittedly, this isn't the nicest solution. What I'd like is a secret project token, but I have been convinced by others that dummy users might be the simplest way to go about this as of right now.

Hence, this mechanism provisions a "bot" user for the org in which the plugin using the API is enabled and a personal API key for this user, using this to execute any API requests. No need to ask users for personal API keys nor project tokens.

Potential Additions

Having started to write this description, I realized it would probably be best to allow overriding the personal API key and the project token, so users can also access other PostHog instances/teams this way, but with the default behavior always being scoped to their specific team, to prevent unintended operations.

Also needs some good docs.

yakkomajuri commented 3 years ago

Reminder to self: Add ability to configure tokens

yakkomajuri commented 3 years ago

Great points, thanks @Twixes

yakkomajuri commented 3 years ago

@mariusandra I guess you mean one per project rather than one per org? Our terminology with project being the same as team makes things confusing 😅

Either way, ultimately this just isn't super clean as a solution, and while a user/key per project would generally make more sense, this would lead to more dummy users. Keys aren't scoped by project anyway so a key scoped by project would still give access to everything else.

Then, regarding 1, there's nothing in this PR that messes with what we already have in that front. And the answer for 2 is I have to check the problems of this not being an email. Might as well give it an "email" I guess but thought that could be confusing too. Will look into options and circle back here.