Hi,
I have several SaaS apps and I’ve never created admin portals for them. I’m finally thinking of developing one, but I’m stuck at the design stage. Should the admin portal be hosted on a subdomain (e.g., admin.example.com) or on the same domain but in a separate folder (e.g., example.com/admin)? Which is safer?
I’d like to hear about your experience and how you design this part.
Thanks
How secure do you need it to be? I prefer to put the admin panel under /admin and use a middleware to prevent unauthorized access. This lets you use the same authentication system, so it’s less work.
If you want more security, you can host it under a subdomain or even a completely separate domain. But that adds complexity for a separate authentication system, etc. So, it depends on your needs. Both are good options.
@Dezi
That’s exactly what I’m thinking. I know I can prevent unauthorized access, but I wonder if there are ways to break that I don’t know about.
Galen said:
@Dezi
That’s exactly what I’m thinking. I know I can prevent unauthorized access, but I wonder if there are ways to break that I don’t know about.
If the users and admins use the same authentication system, make sure all requests to the admin backend go through a middleware. You can redirect users who aren’t admins or just return a 403 error (access denied).
For more security, you can separate the admin panel into a completely different app with a different authentication system. You could also set it up to only allow logins from certain IP addresses and use a VPN to connect from anywhere. (I’ve seen this done, but I’m not sure how it works.)
Consider if the extra time spent on higher security is worth it for you. For all my sites, I just use the /admin option to keep things simple.
Safer depends on your architecture and stack. How access levels and restrictions are set up, etc.
Is the admin panel for you (to manage the SaaS?) or for your clients?
Vega said:
Safer depends on your architecture and stack. How access levels and restrictions are set up, etc.
Is the admin panel for you (to manage the SaaS?) or for your clients?
The admin panel is for me. Users already have their own panel.
Vega said:
Safer depends on your architecture and stack. How access levels and restrictions are set up, etc.
Is the admin panel for you (to manage the SaaS?) or for your clients?
Separate admin panels keep internal and client routes secure. Merging them caused problems for me. I’ve tried Slack and Trello, but Pulse for Reddit worked best for engagement. Separate panels are better.
If the Super Admin (based on what I’ve read) is just for the SaaS, include it with the rest and make sure your authorization system handles it correctly.
However, if they’re all related and integrate via a Single Sign-On (SSO) system, a separate one isn’t a bad idea for control and using APIs to interact with the other apps.
It’s mostly personal preference, but I usually prefer a separate subdomain. It’s often better for security and scalability.
In my case, it’s separate. The components and authentication logic are strong enough to handle multiple application entry points. The applications (client and admin) are in different folders and hosted separately. Versioning has been the least benefit from this.
What technology are you using? If you’re using a Single Page Application (SPA) front end like React or Vue, you’ll probably want to create a separate app for the admin panel and host it on a subdomain or at a specific path that routes to the host.
The main problem with adding an admin page to your client SPA is accidentally sharing code. If you’re not careful with bundling, you could be shipping some or all of the admin-only code to users. Even if the backend is secure, you might not want an attacker to know anything about your admin functionality.
It’s not impossible to set up an SPA system this way, but it’s a lot of work, and I don’t think there’s a simple, 100% secure framework to do it yet. You might be okay with the risk of just exposing the UI! I’ve put moderator controls into my SPA before because I decided the risk was low.
For enterprise, I prefer something like NX to manage shared code. This makes it easier to have multiple apps living together: shared UI libraries, independent front-end apps. Sensitive apps are behind an authentication wall, and no assets are served until the user is authorized.
If you’re using traditional server-rendered pages, it’s fine to integrate it since no assets are sent until you’re authorized.