Web Content Management System History

powered-by.org — Wed, 20 May 2009 10:07:34 +0000

Web Content Management Systems began to be formally developed as a commercial software products in the mid nineties. In the mid 2000s, the web content management market became a fragmented market as a plethora of new providers emerged to complement the traditional vendors. These Web Content Management systems are typically broken down into several groups:

Software as a Service:

AspireCMS,
Clickability,
Knivis,
Crownpeak,
Hot Banana,
Marqui and others

Enterprise:

Sitecore,
FatWire,
Vignette,
Interwoven,
Documentum,
MySource Matrix (Squiz),
Alfresco,
Oracle,
IBM Web Content Management,
SDL Tridion and others

Mid-market:

Microsoft SharePoint,
Kentico,
Goss Interactive,
Contrexx,
Ektron,
PaperThin,
Ingeniux,
Terapad,
Cascade Server,
Day Software,
Logical CMS and others

Open source:

Magnolia,
Plone,
Joomla,
Drupal,
Exponent CMS,
Alfresco,
Sensenet 6.0,
MiaCMS,
MMBase,
TYPO3,
MySource Matrix (Squiz),
WordPress,
DotNetNuke,
MyWebPageStarterKit

Incoming search terms:

dotnetnuke or terapad
web system history

Security overview of Plone

powered-by.org — Mon, 22 Dec 2008 06:55:25 +0000

The ten most common security issues in web applications, and how Plone addresses them.

Below is a list of the 10 most common security vulnerabilities in web applications, and how Plone addresses these. The full background for this list can be found at the Open Web Application Security Project web site.

Problem A1: Unvalidated Input: How Plone handles this: All input in Plone is validated, and the framework makes sure you can never input data that is not of the required type. This is probably the number one reason why Plone sites — even when deployed and developed by people new to web security — are not compromised.
Problem A2: Broken Access Control: How Plone handles this: Plone is based on the well-proven (7 years in production), flexible and granular ACL/roles-based security model of Zope. In addition, Plone utilizes an innovative workflow approach to security, which means that end-users never see or modify the security settings — they only work with security presets that have been supplied to them by the developers of the application. This makes the potential for security errors orders of magnitude less likely to happen.
Problem A3: Broken Authentication and Session Management: How Plone handles this: Plone authenticates users in its own database using a SHA-1 hash of their password. Using its modular authentication system Plone can also authenticate users against common authentication systems such as LDAP and SQL as well as any other system for which a plugin is available (Gmail, OpenID, etc.). After authentication, Plone creates a session using a SHA-1 hash of a secret stored on the server and the userid (HMAC-SHA-1). Secrets can be refreshed on a regular basis to add extra security where needed. Note: Older Plone versions (i.e. before Plone 3) use a less secure method where a session cookie containing both the loginname and password for a user are used. It is highly recommended to enforce use of HTTPS encryption for such sites.
Problem A4: Cross Site Scripting: How Plone handles this: Plone has strong filtering in place to make sure that no potentially malicious code can ever be entered into the system. All content that is inserted is stripped of malicious tags like