Public Website Admin Tools: Divide and Conquer

One of the first steps when designing a web application is figuring out how to administer the beast and where these admin tools should live. Often this comes down to one key question: should the public website itself also be the administrative tool? While there is no single approach that works in every situation, I generally find that keeping the administrative tools separate makes more sense than embedding the tools within the public facing website. Key reasons for attacking this problem this way are:

Differing Nature of the Beasts

Public-facing websites and website administrative tools are, by nature, fundamentally different sorts of applications. Your public-facing website needs to be highly accessible to any number of browsers, platforms and users; it should be highly standards compliant and Google-friendly. From a development perspective, scalability is a massive concern. This means things like completely disabling ViewState and arguably session state, or avoiding such useful tools as ASP.NET AJAX UpdatePanels in preference to much more streamlined scripting.

On the other hand, your administrative tools are likely aimed at a very small set of users on controllable platforms. Bandwidth usage is likely not a major concern, nor are niceties like standards compliance, accessibility and search engine optimization. You can feel much freer to let ASP.NET be ASP.NET and not worry about large ViewState sizes, go ape with UpdatePanels and have massive Session variables and otherwise pretend you are a desktop developer. Its fun and invigorating, not to mention helpful in speeding the development process.

It is far more efficient to just treat each application separately up-front and not have to worry about either limiting your toolset to keep the admin tools nice and public facing nor compromising the goals of the site to keep the admin tool development sane.

Project Management

One fact of life is that issues of importance to the executive types, such as “how will this website look” tend to get delayed beyond all possible belief. Whereas mundane issues, such as “how will this website work” tend to be solved much earlier in the process. Now, if both your logical tools and workflow are dependant upon those executive layer questions, then you can end up in a bit of a bind as you cannot really start significant construction until the big-wigs actually pay attention to the project they requested. But, if you have separated things, you can have a working admin tool before anyone has taken those tough decisions on exactly which shade of pink to use.

Another advantage is, if you have the resources, it becomes much easier to separate the labor between different members of your team as they need not be futzing about the same bits of code. Finally, 3 years down the road, you can give the public website a facelift without messing around with the much more development resource intensive tools.

Security

Using a completely separate application for administration opens up a lot of security options. First, from an IIS perspective, it is much easier to force the administrative application to live under SSL on the web server level. Second, for those of us in the tin-foil hat crew, you can further beef up the transport-layer security by restricting access to the admin tools. This can range from placing them behind a VPN to keeping them within your corporate firewall depending on your deployment scenario.

One major potential security issue is privilege escalation. Now, if you are using “more special” yet public-facing users in your public website to update content, you are one web.config typo away from opening up important sections of your admin tools to the general public. Whereas if you are working with separate applications, then such scenarios are not a risk. You can even use completely separate authentication methods with your admin tools, handy for corporate applications where people are used to Active Directory for authentication.

A final security advantage is at the database layer. Separate applications make it much cleaner and easier to use separate database accounts, allowing one to functionally separate the public permissions from the private permissions all the way down to the core. Meaning that even if something were to get horribly out of whack and a url-based Sql injection exploit make it into the wild, you could still breathe slightly easier knowing your public site’s database user is very, very locked down.

I would not advise taking this approach unless one has already adopted a solid 3-tiered design where the core business logic is embedded in a third assembly. Building websites this way using SqlDataSource is an exercise in folly. But, given a properly structured project, it has been quite a successful method for me.

kick it on DotNetKicks.com

Free book: Jump Start HTML5 Basics

Grab a free copy of one our latest ebooks! Packed with hints and tips on HTML5's most powerful new features.

  • Chris Pietschmann

    I can understand the security concerns of having two seperate apps. One for “public” UI and one for Admin. But it really depends on what type of functionality your application offers. Does it really make sense to have a seperate tool to administer a Content Management System? Why not just put an “Edit” button on the pages when the user is logged in using an Admin account? There are plenty of other cases that would be easier to have a single app, but that’s probably the most common.

  • jazzslider

    The only real inconvenience I’ve ever run into when embedding administrative tools directly into the web front-end happens when I try to do a server-side cache of entire pages. In that case, the user’s access level has to be factored into the cache ID, and sometimes that means that certain pages need to be cached separately for every user. Still haven’t found a way around that one.

    However, in every other way I have found the embedded admin interface to be an improvement over the separate backend, especially from a usability standpoint. If you’re expecting lay users to do content management, it’s got to be intuitive and user-friendly; users (myself included) don’t much like having to learn two separate sets of navigational and interface metaphors for what is, fundamentally, the same system. After all, a database-driven web application is, in a manner of speaking, just an artfully useful interpretation of an underlying database; why make the users learn more than one way of accessing that database?

    Not that I disagree completely; there are advantages, especially from a security standpoint, to having a separate subsystem for administration. I especially appreciated what you had to say about locking down the public database user; that would be a pretty effective help against some common attacks.

    I would caution, however, against assuming that things like standards compliance, cross-browser compatibility, and accessibility are unimportant in the admin interface, especially if you’re not developing for a strictly controlled corporate environment. For instance, in building open source applications, one has to be especially rigorous in one’s standards compliance in both public and admin interfaces, since standards compliance is the only reasonable way to assure the long-term viability of your application in a wide variety of uncontrolled environments. No one can guarantee, for instance, that their open source users will be using Internet Explorer.

    Even though some web vendors disagree with standards compliance in practice, that gap is starting to close considerably…and in that bright future where all browsers interpret standard languages in standard ways, applications whose admin interfaces require non-standard behaviors will likely be tossed aside.

  • Dr Livingston

    > I would caution, however, against assuming that things like standards
    > compliance, cross-browser compatibility, and accessibility
    > are unimportant in the admin interface,…

    I was going to pick up on this point, but someone else has noted it, so I’ll just add that I agree that for administrative areas, standards compliance is just as important and a requirement.

    You can’t get around it, just because it’s not public facing doesn’t mean it’s not just as important; In fact if the standards offered were to drop for the administrative area, I would hold the designer/developer negligent in their duty.

    As for letting ASP.NET [I]be[/I] ASP.NET well, that just about sums up Microsoft’s platform, now doesn’t it? Standards compliant? Pah!!

    That is something they’ve never quite got the hang of, have they…

  • Ronnie

    -Does it really make sense to have a seperate tool to administer a Content Management System?-

    Well browsing the content of a site and creating those contents are very different operations and they need a different interface. Mixing those interfaces is not a good idea. Very basic cms might not need this separation, in fact only amateur cms feature on-the-fly page editing (as far as I’m concerned). Not to mention security and caching problems as everyone pointed out.

  • Bmanam

    Ronnie, I agree totally. Some of the “web app” like CMS’s I’ve had to develop will NEVER have worked with “integrated” administration on the frontend. For vry basic stuff it would probably be just fine but there’s an inherent value in having users have a “tangible” mental separation in what they “do” in the app’s admin backend and what “effect” it has i.e. how it shows up in the end.

    Furthermore, such a separation eventually goes a long way in abstrating the concepts for non-technical users (+ – 98% of my app’s eventual user base). Not to mention the fact that my “backend” development can go ahead in parallel to the design (look and feel) development. Thus, users get a feel for the backend and how it operates before they;ve even signed off on the highly subjective design aspect. As such, when the app/site finally goes “live”, the users are already comfortable with the operation and administration without then having to re-familiarize themselves with the fact that it now “edits in place”. When development is eventually complete, it’s much simpler then for the designer to just hand off the approved design for me to “templatize” and put the dynamics of the Website/Webapp frontend into place. This fact also alleiviates a lot of issues from the graphic designer’s perspective since he can then fully concentrate on getting only his portion of the development spot on since he is free then to specialize in and experiment with different layouts and CSS techniques.

    Perhaps eventual improvements in AJAX and the like will enable us to TRULY make such “edit in place” options viable. I have been part of projects where the administration of content was built into the frontend itself and those projects have, BY FAR, had the most complaints, bugs, and (according to users) a steeper learning curve [beleive it or not] compared to the separated presentation and administration architecture.

    In the end it’s all about the users after all so what’s best for them is what gets done.