ASP.NET MVC - Area or Separate Web Application for Administration?

Question

Up until now I've been using an MVC Area for the administration part of my mvc applications, but recently I've been rethinking this due to the fact that you can't have more than one configuration for forms authentication per application.

This has become a problem becuase in a recent project I wanted to set the auth cookies not to expire for users, but I don't wan't this for administration users. I also don't want the user login page to be used to access the admin tools.

I'm considering setting up a seperate MVC project in the solution purely for admin tools. This seems to me the best option, but I'm wondering about complications with deployment. (Currently I'm using a Web Deployment Project in VS2008 to manage the build).

Does anyone currently use a seperate MVC project for the admin section? Any gotchas? Other opinions as to why this is not a good idea?

Thanks.

Answer 1

I'm always using a separate website for administration. But's it's primarily because the administration for my sites is totally different from the usage and therefore requires a different layout.

Another positive thing is that you don't have to wonder if users might be able to modify stuff that they shouldn't be able to modify since those parts are not built into the user web site.

Update

I mean Layout with Razor or Masterpage with webforms view engine.

We use http://admin.domainname.com and http://www.domainname.com to separate the sites. Quite easy to setup.

Seperating the sites also makes the controllers and views a lot cleaner since they only handle tasks for either administrators or users. No need for a lot of ifs (which otherwise can be very easy to add if you are like me = a lazy coder :)

Answer 2

The forms auth cookie could be path restricted for the admin-area, but that would give you some headache when dealing with the authentication, but might be possible to achieve.

Another option instead of using admin.hostname.com or anything like that, is to use a subapplication on /admin, however that wouldn't necessarily solve your problem.

We developed our web application as two different sites, mainly because we wanted the option to split the administration from the actual site, and also for scalability reasons. We wanted to be able to scale up the actual website in question, and not the administration part.

We have run into the following issues:

1. Preview of content requires certain logic that can will need you to store the actual hostname for the site in some sort of configuration, in order to redirect the admin to the right site as well as dealing with some security-token etc because the user might not be authenticated on the site. This is much easier if you are on the same site (relative paths and the same authentication).
2. Sites that can run on multiple webservers simultaneously (aka, web farm) needs to be designed with that in mind. It involves stuff like cache invalidation, configuration reloads or any other application stored data that might be "modified" in your administration interface. This, however, is a problem in any approach. But, if your site relies on any scheduled work or 3rd party integrations directly in your web application, it might render some issues if your administration site/system is running on multiple servers. Hence, it might be more appropriate to run the administration-system on a HA IIS failover cluster, but the actual website (which is prone to high loads) on a load balanced web farm. This separation of setups is in favor of separate sites.

I think that for scalability reasons, you should consider separating the concerns, however it all lies on the design of your application if this is possible or not. We are building a framework for a certain type of websites, meaning that the actual implementation of the design differs from each and every customer, but we wanted a standardized way to administrate the site, so it was the logical choice for us.

Answer 3

The FormsAuthentication.SetAuthCookie method allows you to control if it persists across sessions or not.

If they're an admin, set this to false, otherwise to true.

See http://msdn.microsoft.com/en-us/library/twk5762b.aspx for more info (the second parameter createPersistentCookie controls this).

In terms of a different login page for different classes of user, you can return false from the authentication method if they're the wrong class of user and accessing the wrong login page.

All of this logic should happen before you set the authentication token.