6

As part of my job I recently started making numerous content management systems for websites. So many that obviously my next step was to set up a 'template' for the websites so I could quickly remove or add elements to suit the clients needs.

Basically I chose Code Igniter, and now am ready to plug it in to a front end.

In the past I placed websites CMSs in a sub-directory of that site, so mysite.com/cms for example. That was using 'spaghetti' PHP however.

Using a framework such as CI or any MVC structure, is it better to host it in a subdomain, keep the front end and the back-end in the same application, or to split them on separate domains? Or does it really not matter?

Improve this question

4 Answers 4

Reset to default
2

I'd suggest it depends on your business needs.

A separate domain could let you standardize an approach, separate the CMS from the Web application, and maybe centralize your site management to a single location.

If you envision providing Content Managent as a service and building your business around providing standard, yet flexible options, separate hosting would be a good choice.

If the customer/client wants to own or control the CMS, then the subdomain approach may be a better fit.

Combining the CMS with the website works if the sites have little customer involvement. If they rarely make updates themselves, there's no risk for a customer to delete, move, or otherwise "break" the CMS.

Authoring needs and functionality are definitely important, but the approach should also fit your business model.

Improve this answer
1

Or does it really not matter?

This. At the end of the day you are still going get roughly the same performance out of the CMS no matter where you put it. The functionality is the important thing.

Improve this answer
0

I will best suggest to keep them on seperate domain.. or if you wish to place the CMS on same domain keep them on strong domains like Blogger.com or worpdress

Improve this answer
0

Looking from the end user's perspective, it really doesn't matter at what address you publish CMS as long as everything works as expected and they're accessing it without problems.

From developers perspective (and I've written and published many as well) it's slightly more convenient publishing it at the same physical location as your front-end, and keep the URL at the same level to the front-end that it 'manages contents of'. This way, you're able to use same configuration files for both front-end generating applications as well as your CMS (or at least keep large portions of them the same, if they need to be separate files), and also avoid problems with relative paths pointing to different roots. It's not the end of the world doing it differently, but would involve a bit more work in most cases.

From security stand-point though, things get a bit tricky. Using easily recognizable URL paths to your CMS means you'll be dealing with potentially a lot more direct attacks, where you won't have time to react to blind guessing, blocking URL scanners even before they hit your CMS with malicious requests. That's fine, if you're confident in your web application security protocols, and in some instances it's even desirable (when web app is also the honeypot). If it isn't however, and you depend on externally managed honeypots (security server mods, log analyzers,...), you might want to rather decide on a non-obvious URL for your CMS, so your honeypot has time to react to 'script kiddie' type requests and block them out. In this latter case, it's also a good practice to 'anonymize' all external requests, such as CMS users opening external URLs through it, where the request referrer (your CMS location) might show in third-party web server logs. Writing an 'anonymizer' script through which you can delegate external requests is easy enough, and it only takes a single JS function call in your CMS main template to enable support for it.

Meaning...

With all this in mind, I'd suggest you host your CMS in a non-obvious URL, at the same level relative (parallel) to the front-end root, but physically at the same location for convenience of developers/designers and debugging purposes, as well as some 'security through obscurity', at least enough to catch the most obvious 'crude' with relative ease before they manage to do any harm. Of course, you should never depend solely on 'security through obscurity' and should always have other protocols in place when the former fail (which they most surely will).

Cheers!

Improve this answer
2
  • There is zero security benefit (while making installation more complicated) to using a separate subdomain for the admin back-end of your web app. If you want to hide your admin area's root URL, just give it a non-obvious URI. Better yet, let the user choose a custom URI if they want. And if you're using HTTPS in your admin area (as you should be doing), then the browser isn't gonna attach a referer header to cross-domain requests in the first place.
    – Lèse majesté
    Commented Feb 25, 2013 at 5:37
  • If you know that putting the admin portal on a separate subdomain provides no security advantages, then why are you suggesting it over an easy to user-configure URI path? Also, the security advantages of an obscure admin URL (especially on an inherently obscure home-rolled CMS) aren't even worth mentioning if you're talking about a site that's not employing SSL for its admin back-end. It's a bit like putting trip wires on your windows when your front door is missing a lock. Before he even begins to think about honey pots and active defense, he should be using SSL.
    – Lèse majesté
    Commented Feb 25, 2013 at 15:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.