Should you let your admin do that?

Admins can do everything in the app, right? Today we discuss a couple reasons why you may want to consider not letting an admin have access to every single feature in your app.

🎉️ Episode 100 is a huge milestone for us. Thank you for listening!

This episode is sponsored by Mailtrap, an Email Delivery Platform that developers love. Try for Free at MAILTRAP.IO

Creators & Guests

Host

Aaron Saray

Host

Joel Clermont

What is No Compromises?

Two seasoned salty programming veterans talk best practices based on years of working with Laravel SaaS teams.

This episode is brought to you by MailTrap. More on them later.

Welcome to No Compromises. A peek into the mind of two old web devs who have seen some things. This is Joel.

And this is Aaron.

On this very special episode of No Compromises Podcast, episode 100, I'd like to talk to you about your boss.

Oh, boy.

Well, maybe not bosses specifically in general, but the idea that there's an admin or some sort of higher level user in your company that uses tools that maybe you develop.

Super user.

Yeah, a super user or something like that. Or, even if you have programmer accounts, I fall victim to this a lot, whereas I give myself a programmer account, give myself all the permissions, and then use that account all the time and I don't necessarily bump into some of the other things that other users would. And that's why you might have unit tests, but not everyone tests every single role type on every single permission and all that kind of stuff. So there's this issue where I could be testing something that works for me but it's not going to work for a normal user or an admin. Which might be a level below my programmer account. So I started thinking the other day, "Maybe there's a problem with giving admins and programmers access to everything."

Oh. I mean, aren't those the people you really want to make happy? Like, who cares if it breaks for a normal user? If the admin's happy, that's all that matters. I want to hear more about that.

Yes and no. But this idea that an elevated user can do something that a normal user can, that's not necessarily always a good idea. So I'll give a concrete example. Let's just say we have an admin interface where there's user management and then these users are like a normal user and there's an admin user. And normal users, when they're logged into the system, they can charge for a subscription, like a credit card. They can put in their credit card and get it charged and then they have subscription added onto their account, and then they have access to all the things. Typical sort of Saas-type things, right?

Mm-hmm (affirmative).

The question is, should the admin be able to charge credit cards and accounts and stuff like that?

Like, on other people's user accounts, you mean?

Well, even on themselves.

Okay.

Yeah. I mean, those are two separate different questions. But in general, let's just start with the easier one, which is on themselves. So a lot of times we set up these things saying, oh, well, if an admin has something, like in a gate check or something, you might just return right away and say, "True". And they have access to this thing and whatnot. But should an admin who never has need for a subscription have the ability to actually access the subscription area and what kind of holes does that open up then? Because maybe your subscription section is based off the idea that there's a standard user with only access to the things standard users can have. Maybe there's a different process that happens when there's an admin. Maybe they can charge against any account and then your... Is that a security hole?

Yeah. That's interesting because normally when I think about this question, it's about additional things we let them do. But you're saying there might be some features a normal user could do that would not be appropriate to let an admin do just because of the nature of their role. Right? They're not going to be subscribing to our internal product, so why even give them that option? That's kind of the scenario, right?

Yeah. And I'm always thinking about what is the extra level of separation that we can give if we're being attacked or things like that driven by malicious users? An admin account is always going to be the highest level or the one that's being targeted. So maybe let's make that less active in other parts of the system. Or maybe it's the same thing as like admins aren't really admins at all, they're just another level called support. And instead of making an admin that has access to everything, you make a support user and you just name it admin for the internal people. But really that only has access to a few things.

Yeah. Not ultimate privileges, but just what they need to get their job done.

Yeah. I mean, you could still argue that they'll need to troubleshoot as users and stuff but that's where that sort of impersonation and taking over an account and stuff can come into play. As long as you're logging that someone initiated that and here's the things that they've done and whatnot. That's kind of how I would think you'd want to solve that more. What do you think?

Yeah, I like that. I have to think a little bit more about the security angle. Because what you're saying... generally speaking, an admin or an elevated privilege user is a juicier target for somebody to overtake. So having that thought process in mind, like they can already do all these elevated things, but there's still some benefit in continuing to think that through. Like, does restricting them in some areas actually improve security? Like that idea of a subscription, does it make the subscription code simpler to not even have to handle the fact, "Oh, this is an internal admin person," and it goes down a different path. And that could be the place where some of those security bugs creep in, right?

Yeah, you actually pointed out the specific thing I wanted to mention, which I didn't. So thank you.

Oh.

Which is that removing some of this stuff actually makes the code simpler and makes the canvas smaller of attack, if you want to look at it that way. So even though you can argue and say, "Well, they still have access to users and blah, blah, blah." Well, the less amount of other features that we make dual ways for them to go through is more efficient and more secure and things like that. So it's not necessarily the target itself of that user account, it's if someone were to do that, can they maybe issue a hundred different subscriptions? For example. It'd be more difficult to log in and overtake a hundred users over and over and over versus just posting a hundred subscriptions with your token with Postman or something.

Yeah, I think I'm coming around. Not that I disagreed but I'm sort of like getting up to speed with the thinking and I do agree it's worth thinking about. Even when you said, "Oh, the dual roles through here," I'm thinking, "It's never just two." Once you go down this path, well, an admin, they can do things this way. But then now we do have this customer support person and they're not quite an admin so now you have three paths through this code. And if you could just avoid that and just have the system deal with the primary use case of the actual user and not have to complicate the code for these other kind of internal support role people, I like that idea a lot.

So I guess the main idea then here is, we're not against admins and people with elevated privileges but do they need access to all the things that you're building in for them? Does it make sense? Sometimes when people say, "Do they need?" it's like do they have permission or should they be able to? It's two different types of questions.

Yeah, two different ways of looking at it.

This episode is sponsored by MailTrap, an email delivery platform that developers love. An email sending solution with industry best analytics, SMTP and email API, SDKs for major programming languages and 24/7 human support. Try for free at mailtrap.io.

This is going back a little ways, over 10 years. But I had a car, I think it was a Toyota Camry if that's relevant for this story. But there's this weird thing that only when I pulled into my driveway I would hear a knocking noise in the head panel. The roof above my head, in there. And it drove me nuts. At first I thought I was going crazy, but what it was is we lived on a hill and so there was a little bit of an incline to pull into our driveway and it was only if I was turning in from one direction, it would cause the car to rotate a little bit side to side and something in the hood... not the hood, the head of the car to knock. So I'm like, "Whatever. Clearly, I can't fix that," right? If there's something loose in there it's not affecting the drivability of the car and it only happens this one time when I pull into my driveway.

What about the safety?

Maybe.

Like, are they supposed to twist and turn like that?

Maybe not, yeah. So you're justifying what I did next, which is I brought it up the next time I was in having the car fixed and...

Customer says, "Car makes weird noise when pulling into driveway."

That's right. First of all, how can they reproduce that? Actually, I was fully prepared going in there to admit, "There's no way I can show this to you." But here's the crazy thing, there was an active recall specifically about this issue where there's a piece of some sort of padding that could work its way loose and there was a remedy and it didn't even cost me anything. So I was ecstatic because I'm preparing to have to try to explain this to them and fight with them, but they didn't. You know what stinks though? After they fixed it, the noise went away but the rest of the hood... I keep saying hood, the head of the car was never the same. Because they had to pull all the fabric down and around the windshield there was trim. It raised the irritation level from the one time I pulled into my driveway I heard this noise, to every time I drove now I could see all these things around me that weren't right. So I guess the moral of the story is just learn to put up with weird noises in your car.

Oh, I would've said, no, just don't accept the car back. Be like, "No, fix it."

We went through two rounds and I reached a point where I'm like it's never going to be the way it's supposed to be.

You're one of those people that complain about free stuff.

Yep, that's me. That's me exactly.

A lot of times for our call to action we get a little silly. But I just wanted to say, from the bottom of my heart, thank you for listening to our podcast over these last couple of years. It's been really kind of an exciting thing for us to see that we can share our opinions, try to make the programming in Laravel world better. And that's just because of people like you.

Yeah. 100 is a kind of an arbitrary number, but it's a big milestone for us. So thank you for coming along for the ride.