Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

CMS Security



On Thu, Dec 31, 2009 at 1:03 PM, Tom Metro <tmetro-blu-5a1Jt6qxUNc at public.gmane.org> wrote:
>
> For example, if there are only a few users who will me modifying
> content, you might be able to use a hybrid solution where the CMS runs
> on a private server, and then gets periodically "published" as static
> pages to a public server. This could be supplemented with some limited
> interactivity on the public server.
>
> This approach gets you the CMS functionality where needed, while keeping
> the public server bare-bones, and complexity is the enemy of security.

I concur.  For a variety of reasons including security-related ones,
it's usually a bad idea to have the CMS framework actually serve your
content.  Plus, PHP-based systems generally have horrendous security
track records (though usually due to poor implementations rather than
PHP itself), so I wouldn't rely at all on the built-in security models
of these systems.

> On the other hand, it isn't necessarily a win if it leads to you
> inventing your own authentication scheme on the public server. Stick
> with something tried and true.

It's usually necessary to integrate with an institutional
credentialing system based on LDAP, Active Directory, etc.  Many CMS
packages have support for these via plugins, but it's easy enough to
integrate directly with these systems, and again safer
security-wise...






BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org