From RNWiki
Jump to: navigation, search
(Created page with '==This is where I (fkelly) propose that we write our filtering standards for 2.5==')
 
Line 1: Line 1:
==This is where I (fkelly) propose that we write our filtering standards for 2.5==
+
==This is where I (fkelly) propose that we write our filtering standards for 2.5 .. this is all draft level stuff now==
 +
==Introduction==
 +
Filtering of data is a fundamental aspect of any web based system.  It affects security, performance and the acceptability of the system to users.  It underlies every other facet of the system.  In generic *nuke (those based on PHPNUKE(tm)) based systems as well as in Ravennuke specifically filtering has traditionally been scattershot or "fractured" -- in other words not based on any set of design principles or standards.  The topic has been discussed ad nauseum in forum threads without arriving at any resolution.  For Ravennuke 2.5 we aim to change that. 
 +
 
 +
The purpose of this document is to lay out a consistent set of standards that all programmers working on Ravennuke software will use.  The document will reference specific functions and programs that are contained (or will be contained) in Ravennuke.  It is not intended as a general reference or to be used outside of the Ravennuke context.
 +
 
 +
==The Flow of things==
 +
Within Ravennuke (and content management systems generally) there is basically a relatively simple flow.  Content for the system is stored in a MYSQL database.  The data in that database gets put in by forms.  The forms are presented to a user (or administrator) who fills them in.  Optionally there can be client side validation of the form before it is submitted.  Upon submission the form is processed by another PHP program.  The "posted" data should be validated and prepared for the database.  Database input or change statements are issued, the database is updated and the user is presented with another form or report. 
 +
 
 +
Within this flow you can see several areas where filtering or validation takes place.  Javascript is generally used for client side validation.  Ravennuke is moving in the direction of using Jquery based validation classes as the foundation for Javascript client side validation.  When the form is submitted there is a layer of software that lies between the form and its processing program to assure that the form comes from within the system, thus preventing cross site request forgery.  A PHP program receives the posted form and validates all data.  Before any data is submitted to the database a specific set of MYSQL related "steps" must be carried out to prevent SQL injection type attacks -- basically adding slashes (escape characters) before certain special characters.

Revision as of 14:03, 30 September 2009

This is where I (fkelly) propose that we write our filtering standards for 2.5 .. this is all draft level stuff now

Introduction

Filtering of data is a fundamental aspect of any web based system. It affects security, performance and the acceptability of the system to users. It underlies every other facet of the system. In generic *nuke (those based on PHPNUKE(tm)) based systems as well as in Ravennuke specifically filtering has traditionally been scattershot or "fractured" -- in other words not based on any set of design principles or standards. The topic has been discussed ad nauseum in forum threads without arriving at any resolution. For Ravennuke 2.5 we aim to change that.

The purpose of this document is to lay out a consistent set of standards that all programmers working on Ravennuke software will use. The document will reference specific functions and programs that are contained (or will be contained) in Ravennuke. It is not intended as a general reference or to be used outside of the Ravennuke context.

The Flow of things

Within Ravennuke (and content management systems generally) there is basically a relatively simple flow. Content for the system is stored in a MYSQL database. The data in that database gets put in by forms. The forms are presented to a user (or administrator) who fills them in. Optionally there can be client side validation of the form before it is submitted. Upon submission the form is processed by another PHP program. The "posted" data should be validated and prepared for the database. Database input or change statements are issued, the database is updated and the user is presented with another form or report.

Within this flow you can see several areas where filtering or validation takes place. Javascript is generally used for client side validation. Ravennuke is moving in the direction of using Jquery based validation classes as the foundation for Javascript client side validation. When the form is submitted there is a layer of software that lies between the form and its processing program to assure that the form comes from within the system, thus preventing cross site request forgery. A PHP program receives the posted form and validates all data. Before any data is submitted to the database a specific set of MYSQL related "steps" must be carried out to prevent SQL injection type attacks -- basically adding slashes (escape characters) before certain special characters.