I’ve been working for about a week now on a complete refactoring of DOMi, which is the class at the heart of Septuro, and the refactoring is nearing completion. Once it is done, I will release DOMi 1.1 and integrate 1.1 into Septuro. Preliminary tests with DOMi 1.1 and Septuro are giving really good results – almost nothing of Septuro needs to be tweaked to work with this new version of DOMi, but Septuro loads significantly faster now.
The main focus of the refactoring was to slim down all of the bulk that had grown onto DOMi since the original AttachToXml function was written nearly two years ago. Over time, new features were added for sanitizing input, checking doc type, disabling prefixes/xpaths and other things that were deemed to be outside of the original scope of DOMi:
“a merger of DOMDocument, DOMXpath and XSLTProcessor, with extended functionality for converting PHP data types into an XML structure and convert the XML into the desired output format”
Now that DOMi has been retooled and cleaned up, it can be put into the core of Septuro to speed up processing times. This will also fix the bug where the root node was always /septuro/module/module instead of just /septuro/module – a bug caused by glitchy processing of importing DOMDocuments.
I’m really excited about this refactoring, because it also introduces unit testing into DOMi, which is the piece that I am still working on. This is my first go at unit testing, but it is coming along pretty nicely. With good unit testing in place, we can ensure that the core of Septuro, the DOMi object, always remains robust and fully capable. It will be very easy to put Septuro onto DOMi 1.1 – from my early testing, only 2 lines of code needed to be changed to work with the new DOMi structure.
Last night, I was up quite late due to the joys of 5 Hour Energy Drink (which is a rant for another time – I was tired as hell, but couldn’t sleep..) and I got to thinking about XSS – cross site scripting, which is a pretty nasty form of hacking. It relies on the fact that most people use cookies to remain logged into certain sites, and AJAX scripts to make requests in the background. For instance, if I set up an AJAX call here at septuro.com that pulled some page like ‘http://facebook.com/delete_account.php?confirm=yes’ and that URL would delete the account of the logged in user, and assume you had already confirmed, then anyone who came to septuro.com would have their facebook account deleted. Even though that attack was carried out by septuro.com, it was technically your browser (and your cookies) that made the request to facebook.com.
Of coure, that example is a pretty straightforward (and totally made up) example of XSS, but the concept is there. While thinking about this, I realized that the way Septuro loads all of its post data, we could set a filtration on XSS (and SQL injection!) right at the core of the system. When Septuro begins to do its thing, it loads all post, get, cookie and session data into a parameters list, which any module can access through a static method in the controller. If the module could always be assured that this data was sanitized at the core, then every module and plugin maker can feel safe implicitly trusting data provided by the controller.
All it would take is some sanitizing functions in the core that filter out XSS and SQL injection attempts at the root level. Combine this with some hooks for plugins to latch onto – for instance an ‘intrusion_detection’ hook, and a plugin can be fairly easily whipped up that uses the ‘intrusion_detection’ hook and the ‘page_request’ hook to add hackers to a black list… although getting the hooks written in is a totally separate matter that still needs some work.
This is like how Linux prevents administrative action at the core and requires a sudo user password. Any program that needs administrative rights can feel safe that the core system made sure that the action has been cleared and is safe. That system kept Linux very secure, and preventing any attack based on get, post, cookie or session right at the core will make Septuro equally secure.
Septuro will be the premiere php framework in the near future. Septuro is using Object oriented programing with heavy reliance on abstraction and modularization. The other open source languages that are uses are html, XSL, XSLT, Jquery, javascript, css, and mysql. We have tried to make it so that you can change out any of these languages without too much trouble. We keep all the languages separated, “keep your html out of my php, I say.” Septuro will make validation changes much easier on the developer by letting the developer change a rule for a validation in the datatemplate and have it changed in the client side Jquery validation and in the server side validation for all properties that are using that same datatemplate. Datatemplates can be for numbers, called numbertemplate. To go further with the abstraction we will be able to extend the numbertemplate into a timestamptemplate by validating that the number is 10 characters long. This way if a property calls for a timestamptemplate it is validating that the property is a number and also is 10 characters long.
Recently, Phil and I were looking at a new system that he is developing for Septuro – where the autoload cascades across the application, parent applications, plugins and finally onto the system core. This is a really cool system that lets you override existing objects with new objects, or even extend existing modules. It is taking the concept of object oriented programming in a new direction, and applying those concepts to entire file structures.
While working on this, we noticed that the plugin directory wasn’t structured in the ideal way, and while looking at the folder structure, we also finally decided to do what Phil has long suggested – kill the element folder and relocate its contents into an object and module folder. I created a new branch today – folder-restructure – where I will be doing all of this tweaking. This really is a pain, but better to do it now than deal with the pain of it later.
I should have this branch finished and reintegrated into the trunk before the end of the day, and then I can get back onto working on the long awaited form plugin. That plugin is going to be really, really cool. I’m excited to get down into working on it. It takes my previous work on the dataTemplates and abstract objects and puts them in a new light. An object can be converted into a form really easily. Just tell the form what object it is working with, the object already contains information on how to be displayed in a form, plus it’s validation rules, and then give it a callback function to execute on completion – it’ll be sweet.
