Webstudio
Log in

Join the Webstudio community

Updated 3 weeks ago

More Granular Access Controls for Shared Projects

yyannick | revaliant
·
Hi Webstudio team,

First of all, I really enjoy using Webstudio – it’s a fantastic tool!

While working on a client project, I noticed something that I think could be improved:
When I share a link to my project, I can disable cloning via the "View" share settings, which is great. However, when sharing a Content link, there doesn’t seem to be any option to prevent cloning or copying of the entire project.

This becomes a problem especially when clients start adding text or media during the early development phase – if someone clones the project at that point, all my input and work can be taken along with the clone, which is frustrating and potentially risky.

It would be super helpful to have granular permissions like:

  • Can copy
  • Can clone
  • Can edit
  • Can publish
This way, I could fine-tune access depending on the person. For example, I might want to give a content editor full access to edit content, but not allow them to clone or copy the entire site.

Just a thought – I believe this kind of flexibility would be a big improvement, especially for agencies or freelancers working with clients and collaborators.

Thanks for the great product and keep up the awesome work!
F
O
y
11 comments
FFedir
+
OOleg Isonen
agree
OOleg Isonen
https://github.com/webstudio-is/webstudio/issues/5187
OOleg Isonen
on the related note: why is your client editing content before they payed for the design/build?
yyannick | revaliant
Addition if I sent someone a View Link maybe I don't want him to see my Code but only the page. At the moment the most restricted Mode is Content Mode because there I don't have Access to the Styles and Structure whereas in ViewMode I can see everything.
yyannick | revaliant
sharing links should follow the Least Privilege Principle — why should someone be able to clone a project if they don’t need to?

In some workflows, especially with long-term clients or agencies, not everything is paid upfront — but work is still being delivered. Even if that's not the norm, it happens, and exposing the full project via cloning or copying creates unnecessary risk.

Clients or collaborators usually just need to edit content or review progress — not access the entire structure, styles, or code. Cloning should be explicitly allowed, not the default.
yyannick | revaliant
As a constructive suggestion, I could imagine a more flexible permission system based on three layers:

Visibility: none / content / full

Editability: none / content / full

Additional rights: can copy / can clone / can publish

Editing should only be possible if the corresponding visibility level is granted. This structure would cover most use cases while staying simple to manage.
OOleg Isonen
Not against adding granular permissions, but I want to get the feel why that's necessary in order to prioritize.

From what I hear is that you should be charging them first before letting them change content if you don't trust they will pay. If its a long-term client and you trust them, then there shouldn't be an issue.

This puts your request on prio 2. Unless you can explicitely argue with my points.
OOleg Isonen
Not allowing them to see how things are made - then you might as well just share the published site.
yyannick | revaliant
Totally fair — I understand this would be a priority 2, as there are surely more critical things to address first.

Still, I think this isn’t just about clients or trust. Granular permissions would also be useful when sharing with other creators or showcasing projects in the community.

For example, I might want to share a project in a showcase context without publishing it. Published pages are publicly accessible via a fixed URL, and taking them offline again is relatively clunky. In contrast, share links are token-secured and easy to revoke, which is ideal for showing something temporarily or sharing in-progress work without making it publicly available or let others see my code directly. At the moment I wouldn't want to showcase my projects through a share Link because everyone cold rebuild it easily but maybe the side isn't ready to get published yet.

To me, “publish” means making a site publicly and persistently available. Share links, on the other hand, are about collaboration, feedback, or limited exposure — and that’s where more control (like visibility/editability and copy/clone permissions) would help cover many real-world use cases.
OOleg Isonen
and taking them offline again is relatively clunky.

That will be fixed https://github.com/webstudio-is/webstudio/issues/2891
Add a reply
Sign up and join the conversation on Discord