Replies: 3 comments 1 reply
-
Either this, or trigger a Supabase function as an authorized user. But exposing GH_PAT is a serious security issue, imo. |
Beta Was this translation helpful? Give feedback.
-
Definitely understand the concern. The reason it's sent to the client is because all the static site generation and uploading to Github happens in the browser, but I'm going to look into just doing the SSG in the browser and sending the files up to the server to get deployed to Github there. It'll add a bit to the build times but hopefully when Primo only generates changed pages it'll be a marginal difference. Also, for what it's worth, the only people currently that could access your PAT are people you invite to your sites/server. But I definitely see the need for keeping it server-side, especially for professional usage. |
Beta Was this translation helpful? Give feedback.
-
Okay this is done now - the PAT doesn't get exposed to the client; instead, pages are generated in a worker & sent up to the server to get passed along to Github with the token. I'll have to look into repo-specific keys when I get a chance. And ideally encrypting the token in the database too. |
Beta Was this translation helpful? Give feedback.
-
I'd feel much more comfortable providing deploy keys with write access to specific repositories instead of a personal access token that grants access to every repository. Is this feasible / something that is being looked into?
Edit: all the calls to the GitHub API seem to be fired from the frontend, so it doesn't look very promising.
Beta Was this translation helpful? Give feedback.
All reactions