Hide/limit options in the server configuration file

[grossmj]

Please add your suggestions to what I would like to hide/limit in the server conf-file. For instance: #1947 (comment)

[lurendrejer]

First of all, will 3.0 have RBAC? Or are we speaking system-wide hide/includes only? :)

[grossmj]

First of all, will 3.0 have RBAC? Or are we speaking system-wide hide/includes only? :)

Yes, 3.0 will have RBAC. It is mostly already implemented and we working on finishing this soon. I will create another discussion for RBAC. Let's focus on hide/includes for this discussion.

[lurendrejer]

System wide:
Hide the ability to use SNAPSHOTS.
Hide the ability to DUPLICATE projects. (Classroom cheating, for instance)
Setting Project defaults: Keep running in background, for instance (instructing users to do this is getting tedious).

more will follow, it's still before 08:00 here - and coffee hasn't kicked in yet.

[grossmj]

Hide the ability to use SNAPSHOTS.
Hide the ability to DUPLICATE projects. (Classroom cheating, for instance)

These could easily be handled by RBAC in 3.0 ;)

[lurendrejer]

Yes - I figured, which is why i'm just sitting tight and waiting. :)

I haven't even reached a point where i got 3.0 running - is it in any way production-like ready if I put in the effort?

[grossmj]

I haven't even reached a point where i got 3.0 running - is it in any way production-like ready if I put in the effort?

We aim to create nightly builds in the coming weeks so anyone can start playing with it. I have created a new discussion for RBAC: #1949

[srieger1]

These could easily be handled by RBAC in 3.0 ;)

Sweet! I suppose, filtering the project list to show only a subset of projects available on the server will then also be possible using RBAC? We currently use gns3-proxy for that to display, e.g., only projects belonging to a specific course.

Also, we deny/filter some POST/PUT/DELETE requests, to, e.g., help esp. undergrad students to not accidentally break projects.

I can think more about that in detail maybe in the upcoming days. There are also examples for denied requests in the [deny] section here:

https://github.com/srieger1/gns3-proxy/blob/develop/gns3_proxy_config.ini

[srieger1]

Just saw your recent post describing the RBAC implementation in detail. Awesome! I think all of the things I mentioned should be covered by your approach. I'll try to find some time to think about possible other limits etc. in the config file, but for now I have the impression that RBAC covers all of our requirements in this regard.

[grossmj]

Sweet! I suppose, filtering the project list to show only a subset of projects available on the server will then also be possible using RBAC? We currently use gns3-proxy for that to display, e.g., only projects belonging to a specific course.

Projects are automatically filtered in our current RBAC implementation, an user only sees his/her projects. However, we don't have the concept of group of projects in the API to easily filter multiple projects (for now you would have to create permissions that match specific project UUIDs). Would this be a limitation for you?

[srieger1]

The option to group projects for lectures etc. is more or less a convenience issue. I think it's totally ok and understandable to limit filtering to the UUID only. Also took me some time to figure out a way to filter by project name and copy/replicate projects by name etc. instead of the UUID ;) However, UUID is the only/best way to ensure a unique identifier. Maybe that's some work that will still be left for us when 3.x is released, to come up with some mapping or so from a group/course/role name to all UUIDs belonging to that group/course ;) As long as groups are not possible. Like I said, no big deal and not a limiting factor for us. To have RBAC in GNS3 is a big step forward. Thanks!

[lurendrejer]

@srieger1
Just i side-note here, I had some template projects with manual UUID's to do just that, i simply changed the UUID's to AAAAAA-AAAAA-, BBBBBB-BBBBBB, etc.