So, you’re designing a new feature in PHP for an application. Like most good programmers, you have a data layer and a business logic layer. But where is your security layer?
For the most part, whenever I design a new feature, all the security goes into the business logic, because the data layer should be “dumb”. Well, this is annoying because 1) I have a lot of repeat code and 2) it’s very easy to forget something. The ideal place for it is really the data layer, but this is bad practice because you limit the data layer’s flexibility.
Then, while driving to Wendy’s for a #8 today, it hit me. The perfect security layer. Unobtrusive. Simple. Elegant.
The beauty of PHP is it allows a perfectly transparent wrapper, without a lot of code. Through the use of __get(), __set(), __call(), __isset(), and __unset(), a class can be mapped perfectly to a data object. Therefore, you can just pass a data object to a security class in the constructer. Then, anytime a function or class member is accessed, perform security checks if needed.
I haven’t designed an abstract base class for this object yet, but I am going to very soon. It should help to not only clean up code, but secure the code. Definitely going to be an addition to Wack v1.
Since Mike doesn’t really blog anymore, I figured I would steal his thunder and discuss some of his findings the past week.
For those of you that haven’t used Prototype before, it is a Javascript library which we use fairly heavily at webmail. It has served us well for a while now …..
But version 1.5 is becoming too slow to be used in webmail. Being a very large web application, we don’t always have the luxury of elegant code, especially in javascript. Sometimes, we just have to do what works fastest and looks the ugliest. This past week Mike made some interesting findings, singling out some of the major performance culprits in Prototype.
Enumerable.each()
We have known this function is slow and have tried to avoid using it, but Prototype itself uses it on some very common functions such as:
- Element.addClassName()
- Element.removeClassName()
- Enumerable.* (Basically all of them use each() somewhere)
Mike overrode the first two functions to use a regular loop instead of each() and saw a 200ms login improvement! That is a pretty large improvement, nearly 14% of the total javascript rendering time on login.
Element.update()
For a long time, I thought Element.update() just abstracted element.innerHTML. I was wrong. It calls stripScripts() and evalScripts(). Since we never pass in text containing script tags, we overwrote this function to just use element.innerHTML. Again, another huge performance enhancement.
Unnecessary abstractions
Prototype has added some great functionality to javascript, but sometimes they take it a little too far with their abstractions. Some functions serve very little purpose other than to add an extra function call.
- Element.update() - Since we have taken out the stripScripts()/evalScripts(), there is really no reason to use this function
- Element.setStyle() - As long as you don’t set opacity or float styles, don’t use this function.
- Element.addClassName() - If you know an element doesn’t have the class name already, just call element.className += ‘ foobar’.