Up until now, web designers (or web programmers) are trying to make their httpGET or httpPOST input more secure by filtering it. This has a side-effect which limits the number of characters allowed for a password or username. What if someone wants to have an equal-to (=) character, or even a quote (") character? These characters are known for it's ability to achieve SQL injection. However, I will further explain how they can not.

The old school method of filtering these kind of input is by limiting the characters so that caracters like equal-to (=) or quote (") can't be used. After the filtering is done, then, the input is passed to the SQL command, and then executed. This practicular method involves inserting some PHP variable (or any other language's variable) into the SQL command line. When you forget to sanitize the input, hackers will be very happy to infiltrate your system.

Now, I want to introduce you to a method used in my OOCMS project, which is extremely secure for any kind of SQL-involving input validation. I call it "Separate Room SQL Validation Method", or SRS-VM for short. Instead of letting the SQL part to do the selection job, I use the PHP part to do that. So, I do that by pulling all of the SQL query which is involved in the selection proccess into an array, and then comparing the input to the array. If a match is found, then you'll be able to proceed. This method involves no variable insertion at all, so the SQL command is a clean SQL command without any interference from the outside. That's why I call it "separate room". It will cause a big overhead for a big database, that's for sure. However, the lag is almost unnoticable.

If you want to further understand this method, hit my OOCMS git and go to the framework/controller directory, and open the janitor.php file. I use it in almost every fuction it that class.

That's all from me, and happy blogging!

The OOCMS (Object Oriented Content Management System) has been out in the wild for several days now. You can view it here. It is now half finished, still need an Admin panel though.

It seems that building with OOP and a better background in web programming makes the coding time shorter. It only took several days to reach this stage which originally it took more than a week. I'm confident that all of the framework (excluding CSS and better index formatting) will be done (default-system wise) at around 23rd of October.

I'm currently working alone, and it's not a problem for now. However, when the default framework is finished, I'll be looking for independent developers to help me extend its capabilities, including some hardcore javascript implementation, and also not to forget, HTML5 based publishing (something similar to photoshop, movie editor, and sound editor) and webGL.

Let's hope the best for this project, and may it benefit people abundantly. Happy blogging!

When I'm learning about the application of OOP in web programming, I come across something called MVC (Model-View-Controller). It's an architecture for an application which allows the application to be easily configurable for different UI. Basically, it allows the same application to be viewed across different type of devices.

The controller is basically a layer which receives all of the input from the user, validates it, and execute the requested action. It has some type of input sanitization, and it knows all of the other element in the application in order to tell them what to do.

The model is a layer which handle all of the business logic, data abstraction and data processing. In conjunction to input-processing-output mechanism, the model layer is comparable to the processing part, while the controller is comparable to the input part.

The view layer, as its name tells, is a layer that allows the user to view the requested content/action. It knows nothing about database or any data sources, it only knows that it needs to render the content provided by the model.

However, when I dug deeper into the MVC architecture, I also come across PAC (Presentation-Abstraction-Control). It basically is an altered version of MVC, where the Model (in this case the "abstraction" part) can't directly access the view ("presentation"). The abstraction layer needs to transmit the data stream to the controller, and when the controller done validating the data stream, it tells the presentation layer to render the data accordingly.

Why do I write about this? It has something to do with the main concept of the blog engine. It will use PAC as the base architecture. It's secure, because all of the data transmission is controlled in one layer (try to beat that, hackers!). OOP will sure be used as the basic paradigm of programming the blog engine.

That's it for today, and, Happy Blogging!

update (2011/10/12 13:15 GMT+7): I will temporarily use MVC for the beginning, and move to PAC as I understand it better.