What’s your idea?
Not sure if there’s another way to go about this, but I noticed that whenever I add new tables, all of the roles default to having permissions to read/update/delete everything on that table.
I am not sure what’s the best way to go about this, but two possible ideas are:
- Add an option to specify what the permissions of each role defaults to for new tables (in the app services tab when clicking on a role and looking at permissions)
- Add a way to specify which roles have permissions to read/update/delete that table when creating it (in the data tab when creating a new table)
I personally prefer the second option, but would love to get some thoughts on this.
What problem might it solve?
Currently, if I create a table but only want some roles to have access to it, I have to remember to manually edit permissions of those roles to remove access. This could easily create security vulnerabilities/inconsistencies, so it would be great to solve this in a way that doesn’t solely rely on memory.
1 Like
I disagree with this.
I would much rather do all the dev-work without blockers.
Add data to it whether it be import or through triggers / tasks and test out if everything works clientSide.
THEN when everything is working. Set up permissions / Roles
When creating a new Table you are usually creating a new Feature. As a developer I don’t want to worry about whether my feature doesn’t work because of Permissions when just starting development of it.
And the 8Base UI and UX is superb! It’s super easy to set up roles and set permissions. It’s not a hassle whatsoever.
I would much prefer it to stay as is.
@MarkLyck how have you made sure you and other developers remember to go back and edit permissions of those tables before shipping the feature? That’s the main thing I struggle with – I just realized all users in my app had permissions to see data from the past couple tables I added, but they shouldn’t have. This can easily create privacy issues. This could’ve been caught with more testing, but it would also be great if the UX of 8base helped reduce the likelihood of this happening.
And I agree that the UI/UX of setting permissions is good, but it is a completely different flow than creating tables, so it’s more about not relying on developers to remember to remove unnecessary permissions before shipping than it being confusing/too hard to work with.
How do you see being able to set permissions when creating new tables be a blocker? If the default option stays the same (everyone can read/update/delete), the behavior would also stay the same, but it would also allow developers to edit permissions right away.
Definitely happy to hear suggestions about how people have been handling this or ways to improve it in 8base!
Hey everyone - I understand the issue here and agree with what’s been said on both sides.
Right now, creating a new role grants all CRUD permissions for that role to existing tables, or creating a new table grants CRUD permissions for that table to existing roles. Personally, I do not like this. This system shouldn’t grant permission by default. Instead, the default should be a user or role has NO permissions, and all permissions need to therefore be explicitly granted.
2 Likes
@sebastian.scholl I like that approach as well. Is it on the roadmap?
Slated on roadmap for this quarter!
2 Likes
This is definitely a need for us as well - specifically in a security sense.
Scenario:
- Developer creates a table with sensitive information such as passwords, environment variables, etc.
- Developer goes back to the app, queries/mutates from 8base and everything works. Doesn’t realize the need to restrict access.
- All users now potentially have access to this sensitive information.
- Security risk is found and an e-mail is sent letting them know that their data (in this case env variables) were exposed for a period of time
This scenario could happen often as its an easy thing to forget to configure something (for example API access) if it works and could have severe repercussions.
2 Likes