Limit stream access to registered users

Hi all,

When a Speckle server is set up within a company, it would be very helpful to have an access level option of “registered user”. This would allow free sharing of data withing the server (and with any collaborators who have access to the server), without requiring either free access to the data to anyone, or adding each individual person to the stream.

Would this be useful to others?

This is something we’d be happy to contribute, and I thought I’d float the idea before we slot it into our plans.


Good idea! I can see this being useful. You could share some example streams with everyone on the server without sharing it with the whole web.

Edit: thinking about it, it might also be useful to differentiate between colleagues and external collaborators. E.g.: example streams containing company sensitive data you’d like to only share with colleagues, but not with clients or other parties.


Hey all, this is a good shout. How we are thinking to implement this is around the future concepts of “Teams” (or organisations), rather than just blanket server-wide. One default team could be, of course, the whole server, but it’s important to have this concepts a bit better baked in.

This will be a deep auth & permissions change that will have quite a few ramifications across the whole server code, so, if not urgent, I’m going to play for buying ourselves some extra time to think and scope it out in the near future before we jump on it! We’ll start a thread in the coming months on getting this fleshed out.


Hey @dimitrie, I understand that a proper implementation of teams / orgs / projects in definitely non-trivial, and thought that a server-level access level would be a simpler step that would still be useful no matter what the details of the teams / organizations system ends up being.

Within Arup, as we look to move Speckle from being a tool for tech-savvy early adopters to being a platform that changes the way whole teams collaborate, support for projects or teams is a key capability to support this.

We are planning to start our big v2 rollout in October and I would like to have something minimal in place by then. A short-term solution we are considering is to tag streams with project numbers (using Globals), and to create a plugin webapp that shows all the streams for a given project, allows the creation of streams (with the relevant tags filled out, and provides a shortcut for assigning access). This is a bit hacky, but will allow us to gather feedback and support early teams uses and then eventually migrate to the new system.

1 Like

Hello @dimitrie and the wider Speckle community,
I also think the “user group” or “team” permissions would be a great feature. We have a use case where we would like to set up a “collaborative” environment on a project server where all registered users would be able to contribute to a given stream. By everyone, I mean a team of 20 to 30 people who might change with time. So having to set personal permissions at the stream level every time the team grows/shrinks seems quite a hassle.

On that note, while waiting for a long-term solution, is there a way to get a list of all registered users on a server? I know we can query the api for a specific user but can we do that for all users? That way I can programmatically set permissions to everyone registered whenever a new stream gets created - a temporary workaround to the above mentioned issue. Or do you maybe have a better suggestion on how to deal with this?

Thanks a lot for your time :upside_down_face:

Edit: Also, is this considered the correct/fastest query to grant permission to more than 1 users in the same request?

mutation { M1: streamGrantPermission(permissionParams:{streamId: "xxx",userId: "yyy",role: "stream:contributor"} ), M2: streamGrantPermission(permissionParams:{streamId: "xxx",userId: "zzz",role: "stream:contributor"} ) }
I tried passing a list in the variables but it did not work. :frowning:


@gjedlicska is working on this right now, as part of the admin features bucket list effort!

To prevent future spamming, the api is restricted to one user permission grant per call. Nevertheless, until we get to implement rate limiting (wow, this issue will have its one year birthday soon!) you can probably get away with sending those in a for loop :sunglasses:

While I realise this doesn’t really solve your short term problems in full, I’m actually happy these problems exist, as it means you’re probably putting speckle through quite some exercises :raised_hands: