This is very closely related to #31 to the point where there's probably a single solution which can be used in both places. If we also implement #19 then this fine-grained access control will work for client certs as well.
I have some basic thoughts on how this would be implemented, but for now I'll just describe the user story.
Now that I'm starting to convert the MAGFest code to use Sideboard I'm contemplating more of what I'll need to actually use some of our built-in freebies. The crud interface is pretty great and I'd love to use it, but there's the question of access controls. Our original projects all just had one type of access level: administrators with full access to everything. We always knew we'd need more ways to lock things down, but we punted on it because it wasn't relevant to any of the projects we were working on at the time.
Here are the different types of users which do things with the MAGFest code:
Regular attendees who preregister. Although they do end up saving things to the database, the implementation wouldn't use the Crud interface anyway, nor do they currently consume any services, so we can just give them no access.
Volunteers who sign up for shifts. They won't need to use the Crud interface either, but this is an Angular app which I'd like to consume actual exposed services. So it would be okay if we just had some way to say, "you can consume any service except the Crud one".
Administrators. These have access to different parts of the site. It's not a ladder where some admins have a "higher" level of access to the site, but instead we define different site sections to have access to specific things like "Registration and Staffing" or "Inventory and Scheduling" or "Budget". So theoretically we'd want to be able, on a per-model basis, to define what someone can do on that model.
I should probably study the Django REST framework a little to see how they handle this. If there's some elegant solution that already exists, then I'll just gank that. Otherwise I feel like I've got a pretty good handle on how I want to approach this.
This is very closely related to #31 to the point where there's probably a single solution which can be used in both places. If we also implement #19 then this fine-grained access control will work for client certs as well.
I have some basic thoughts on how this would be implemented, but for now I'll just describe the user story.
Now that I'm starting to convert the MAGFest code to use Sideboard I'm contemplating more of what I'll need to actually use some of our built-in freebies. The crud interface is pretty great and I'd love to use it, but there's the question of access controls. Our original projects all just had one type of access level: administrators with full access to everything. We always knew we'd need more ways to lock things down, but we punted on it because it wasn't relevant to any of the projects we were working on at the time.
Here are the different types of users which do things with the MAGFest code:
I should probably study the Django REST framework a little to see how they handle this. If there's some elegant solution that already exists, then I'll just gank that. Otherwise I feel like I've got a pretty good handle on how I want to approach this.