Configuring Developer Roles with Limited Data Access

Speaker 1 (00:03)
Hey, everyone, this is Sebastian. Today we're going to be looking at how you can configure roles and permissions for your developers so they have limited data access or maybe feature access when working within the console. Here I'm in the 8base console and the first thing I think is really important to mention is just an architectural feature of 8base. Which is that the entire 8base console experience is just a front end to your workspace API.

Speaker 1 (00:29)
What that really means is anything that you can do or that you do do in the console can be programmatically performed via the GraphQL API. Really an 8base workspace is just one big workspace API and this is our front end to that. Now that means that the same type of roles and permissions that we would create or use for users of the applications we build to interface with the GraphQL API is the same type of authorization system that the 8base console uses when communicating with that API. We end up defining roles and permissions for our developers the same way currently that we define roles and permissions for our end users.

Speaker 1 (01:11)
Now, let's create a developer role to demonstrate this. Let's go into our app services and here in roles, let's create a role and we're going to call it Developer Level 1 Role. This description which is obviously just a description will be a developer role with limited data privileges. I can't spell. There we go. Cool. We're going to have this role.

Speaker 1 (01:43)
Essentially what we're trying to accomplish here is we want to be able to invite developers to collaborate with us within the workspace, but we don't want hem seeing all our data. We're going to create a developer role and now permission what data that user can or can't see, whether it's via the API when they're working or logged in or more specifically here in the console.

Speaker 1 (02:03)
Once I open up the Developer Level 1 role, we have a few different tables in our workspace here. What we're going to do is we're going to say, okay, well, we don't want them to be able to delete any of these records, but we want them to be able to see them all. Then when it comes to the invoices, let's say that we actually don't want them to know how much each invoice is worth, that's private. What we're going to do is we're going to say the order value is none from an access standpoint. Even though they can see the records and potentially update the records, they can't interact with that field, which is the order value.

Speaker 1 (02:42)
We're also going to allow them to see every user in the database and you'd be able to see the user records. However, they cannot update any user records. Then what we want to make sure, is that we want to make sure that they actually can't snag all our users' email addresses. What we're going to do here is we're going to say that, hey, they can't view or update obviously the email field and we're also going to make it so that they can't interact with the last name field. All I can do is the first name and the other information, those ones aren't available to them and save that.

Speaker 1 (03:18)
Now this was configuring some of the data permission, so what operations can they perform on the records, such as we don't want them deleting records, as well as what data fields we want to hide. For example, if we were storing a Social Security number let's say on the user's table, we would potentially want to mask that so they can't see it. Then if we jump over to the apps tab, we can now also say, hey, here's some of the different system areas in the console that we do or don't want them to have access to. For example, we don't want them to be able to change our schema, but we do want them to be able to access the data viewer, so we're going to turn that one on. For now, let's just leave it here.

Speaker 1 (03:56)
Now that that role is configured, I'm going to go over to the settings, team area and I'm going to invite my first team member and I'm not going to give them a name, but I am going to give them an email address, which is sebshaw@gmail.com, and I'm going to assign them this Developer Level 1 Role and send off the invite. Me as the admin working this workspace, I can do everything. However, once this sends off, cool, invitation pending. I'm actually going to switch tabs here to where I'm logged in in another Chrome window to my sebshaw account.

Speaker 1 (04:41)
I'm going to reload it and here I can see that I have a new inbox notification in my developer home. I'm going to open that and I can see that Sebastian Shaw has invited me to join their Sandbox Workspace 00001. I'm going to accept that invitation. That's accepting the invitation with the associated role. Now when I go back into my developer home, I can see that I have access to this workspace. Cool. Let me open it up.

Speaker 1 (05:16)
Now it's open and the first thing I'm going to do is jump right into the data tab. Now when I go into the data tab here, I can see that it's not giving me any option to add new fields 'cause the schema wasn't enabled or scheme management was enabled. But what's cool is that if I go to my invoices table here, I can see that 8base has hid the order value, so that's not being returned 'cause I don't have permission to view that field. Same with if I open up the user's table, I can see that, hey, I have access to all the different fields except for the, what's it called, the email and the last name. Those fields are hitting me too as the developer.

Speaker 1 (06:00)
Now, if I were to try to delete a record, let me try to do that really quickly. So loads, cool. If I were to go in there and click delete it's not giving me that option. I could edit it if I wanted to because I left that available. As you can see, it's customizing console experience to allow me or not allow me to do the things that I am or am not supposed to do.

Speaker 1 (06:31)
Once again, even if I were to try to say, hey, give me a query back from the invoices list where I want for every item in there the order value, I run it, seem I'm having a little slow Wi-Fi at this point. Cool. We can see this just saying there's no order values, which is not true. Every invoice has an order value, but it's masking that field for us. Still returning the record because we have access to those records, but hiding the field.

Speaker 1 (07:11)
I hope that this gave you a good understanding of how you can create roles and permissions for your developers, and by doing so, how that will impact the developers' experience when developing or working within the console or interacting with the API. Now, one other cool feature about developer roles is that they can be permissioned on a per environment level.

Speaker 1 (07:33)
If you are using CI/CD and you have different environments such as production, development, staging, QA, feature branches, all that type of stuff, the roles that you create in those environments can be unique to those environments and then when you invite developers to work in those environments those will be working as you'd expect there. That gives you a lot of flexibility then in saying, hey, in the development environment, the developer can see all the data because they're developing new features. However, the developer in the production environment where the data is sensitive can only see certain things.

Speaker 1 (08:07)
A lot of different levels of customizability or customization that you can do to make sure that you're are securely giving access to your project, to the developers as it's needed. Now, if you found this video helpful, please subscribe to the channel. Hope to see you in future videos and happy developing.

‍