hmmmmm
Yes, if you have the project token you can sync or ask for the loader response from the server, this even if you don’t have share by link enabled, share by link is expected to be a studio only blocking, but I do see the point of blocking it for codegen as it has the more direct visualization of the code.
I think there was some misunderstandings in the thread about which token is being referenced, but the idea of the project public api token is to be a public token similar as to other public tokens in cms or ecommerce tools, for example the shopify storefront access token (https://shopify.dev/docs/api/usage/authentication#getting-started-with-public-access) which allows you to fetch the content that is present on your store. But in plasmic this allows you to get the representation of your project as code.
Just reiterating that this token is a read only token, as similar to other tools. But I think the concerns that you guys are bringing is about the generated code having content that’s not ready to be exposed, right ?
I will try to compress an answer regarding the bard response in my next message.
Just reiterating that this token is a read only token, as similar to other tools. But I think the concerns that you guys are bringing is about the generated code having content that’s not ready to be exposed, right ?
Right
Just reiterating that this token is a read only token, as similar to other tools. But I think the concerns that you guys are bringing is about the generated code having content that’s not ready to be exposed, right ?
Maybe I should step back a bit to give you a more concrete example. One thing I’ve been experimenting with is the data integrations through plasmic with the generic HTTP connector. I can see the generated code makes those calls with the parameters it needs. I’m not intending to expose those calls made by data integrations on the client, I’ve set things up to do this on the server.
In theory right now, if someone get’s hold of this api token they can:
• sync my source code
• figure out how to make this HTTP request through the generated code
• make the request and get data that I haven’t given them permission to retrieve (since I was only intending for this call to be made server side)
I do understand that the page will ultimately contain some of the data in the request, but it probably won’t contain everything.
It’s highly possible I’m going about this the wrong way so forgive me if that’s the case 
This is just one scenario I could forsee where someone gaining access to source code through the public token could be an issue.
Sorry to have stepped away from the convo for a while.
The generated code would just make fetch requests like any other client. Could you be more specific about the issue here?
Also this doc describes how security works for data integrations: https://docs.plasmic.app/learn/integrations/#security
Also, sorry about https://plasmiccommunity.slack.com/archives/C0128PVPESU/p1702412707832309?thread_ts=1702409480.338739&cid=C0128PVPESU
I think I mislead folks about sharing affecting the ability to sync/load. The sharing only affects who can view/edit a project in Studio. I edited the above message to reflect that.
The generated code would just make fetch requests like any other client. Could you be more specific about the issue here?
I think the point I’m trying to make here is, what if the intention is for this request to be made on the server during the SSR phase of a request and I don’t want people to know the specifics of how it’s happening?
This seems to be possible to not expose these fetch calls using the extractPlasmicQueryData helper within getServerSideProps in Next.js. Once the page is rendered and sent to the client, it’s already populated with data so the client doesn’t see how the data is fetched.
Ah ok I think I understand. In SSR, maybe you pass in a secret header to enable access to an internal-only API? Then the call would only work on the server and not on the client, though the client will still include the code to fetch.
So this might expose details about the fetch call, but wouldn’t actually provide access to it.
Yes that would work! So I think what I’ve taken away from this whole thread:
• the project API token is indeed meant to be public, because there are times where it needs to be used from a public context like a browser
• you can use codegen to sync any plasmic project if you have both the project ID and api token, which in theory, allows anyone to generate the plasmic source code of a website (regardless of sharing settings)
• I should maybe rethink using plasmic data integrations for HTTP requests I want to only perform server side, since it get’s included in generated code. This can create a situation where data could be exposed that wasn’t meant to be fetched on the client
◦ If I want to protect this, it should probably be done as some kind of custom code component and then injected from the application code itself
Hopefully that makes sense, still getting my head around all the pieces of the platform!
ya, I think the other thing I’d add is that if/when you use “publish to github” the project ID and API Token are shared in the GitHub Actions
About the bard response, I believe most of the mentions are related to the exposure of a ideally private token, instead of a known public token, but here it goes:
• Insecure Direct Object Reference (CWE-665): An attacker wouldn’t be able to manipulate it, as it’s stated that is a public token, the access to the project itself can be controlled in the studio.
• Information Exposure (CWE-200): I believe this is the one that actually fits your concerns, as this token can give access to the content of your code, @carefree_muskox worries about data sources are valid, we currently don’t have a code generation model that would only contain the data source instrumentation in the server end. You could use auth to protect your application, which would solve the issue, but I understand that’s not always a reasonable option.
• Insufficient Logging and Monitoring (CWE-352): Not applicable, as it’s ideally public
• Missing Authentication for Critical Functions (CWE-306): Read only public token so no actions could be taken with it.
• Use of Hard-coded Credentials (CWE-798): Read only public token, that can be exposed in client context as browser.
• Improper Access Control (CWE-285): Same as above
• Uncontrolled Resource Consumption (CWE-704): It wouldn’t be possible to delete resources, it could lead to an excessive resource consumption, but it wouldn’t be related to token exposure, as anyone could create a project and try to excessively consume it.
• Cross-Site Scripting (XSS) (CWE-79): Not applicable, as it’s public read only token.
Even with the consideration of token I do see the concerns, I believe we can remove the token from the plasmic.json so that it’s not a worry when doing commits of codegen code, I will take it as a question for the team.
thanks so much for the response! I should have mentioned I didn’t think they were all applicable but it was my birthday yesterday and I was distracted
No worries, hope you had a happy birthday