Open istarkov opened 1 year ago
Probably we need some naming for prod context creation, like createContextWithBuildEnvProd_DO_NOT_USE_IT
Also, as of now we don't have a working publish at opensource, probably it can be only development issue. In that case buildEnv can be a synonim of NODE_ENV !== "production"
Maybe something like createViewAnyProjectContext
if that's what it actually does?
Now at open-source previews | dev-mode we use Canvas to show production builds. And it reads project data from DB directly. That's why we have buildEnv parameter in the AuthorizationContext https://github.com/webstudio-is/webstudio-designer/blob/124ab25174ea9faca2290f6377038541b5f4cd8b/packages/trpc-interface/src/context/context.server.ts#L24-L27
If it is set to
prod
we allow view access to the project. If it ok for development and previews it's a security hole for SaaS/Self-Hosted projects, as allows to get access to all the sources of a project.Now it's used in 2 places.
To show production build on canvas at preview/development and not used at production (SaaS) from what I know https://github.com/webstudio-is/webstudio-designer/blob/124ab25174ea9faca2290f6377038541b5f4cd8b/apps/designer/app/routes/$.tsx#L55
To clone project into KV storage at SaaS https://github.com/webstudio-is/webstudio-designer/blob/124ab25174ea9faca2290f6377038541b5f4cd8b/apps/designer/app/routes/rest/project.$projectId.tsx#L22
2nd case is used at SaaS now, but used by our worker and the endpoint can be protected with API KEY as its interservice communication.
What to do
/routes/$.tsx
endpoint/rest/project.$projectId.tsx
endpoint with API_KEY as its interservice communication and should not be accessed directly at all