: Best location for a websites CMS 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'

@Cugini213

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

Vote Up Vote Down

@Hamm4606531

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!

Vote Up Vote Down

@Kristi941

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.

Vote Up Vote Down

@Barnes591

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.

Vote Up Vote Down