Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
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 | |
We also thank MIT for the use of their facilities. |