All posts tagged "php"

So, I started a new job. And the first thing I get to work with is a large PHP application for managing Wireless Hotspots. The application presents a portal page to people trying to connect and handles payment and creation of the Radius info to allow them to use the service. The PHP element is mainly a large and complicated database frontend, with a few special functions to interface with some other systems. Anyway, the thing was originally written about 5 years ago in PHP 4.2.2 and the code makes me shudder.

So, I gave some thought to how I would do it if I was writing the same thing from scratch. I immediately thought "Cake" but then realised that for a commecial application I would want to fully understand all the under-the-hood business and as good as CakePHP is, I don't have that full understanding. So instead I thought about writing a framework from scratch - albeit based on many CakePHP principles.

Requirements

The first thing to think about is what you want the framework to achieve on it's own before we start to think about building the app on top of it. This project has some features which must be available in the framework.

• Multiple points of entry:

  The application is accessed from 3 different places, and they will share much code.

  • The user interface is what a person trying to connect to the wireless network would see.
  • The customer interface is a Customer self-care portal for a hotspot provider to manage their hotspots.
  • The admin interface allows management of the entire system and reporting.

• Multiple Databases: specifically, their are 2 databases in use, the "main" one and the Radius AAA database.

• Authentication and Accesss control: for the 2 restricted interfaces, this should be ingrained into the framework at a low level, but extendible to accept different authentication mechanisms.

• Licensing: this product may be sold under license so the ability to restrict capabilities is required.

Design

The next think to think about is how the framework will be put together. I leaned heavily on the cake approach in designing the basic structure of the framework. I tried to imagine the flow of a request and what I would need to build to make it work. So I got the following:

1. Index.php: accepts the request set's some paths, loads a common "boot.php" file.
2. Boot.php: loads the generic functions (including a "Loader" class for autoloading other classes), loads some config options from "ini" files, creates a Dispatcher instance and starts the ball rolling.
3. Configure.php: handles the config options loaded, a "Globals" replacement.
4. Dispatcher.php: co-ordinates the request. Processes POST data, gets info from Router class, and instantiates our Controller, and creates and renders the View.
5. Router.php: Router class does forwards and reverse routing, extension parsing and parameter handling.
6. Controller.php: has methods to set options for the view.
7. View.php: takes the request options, controller settings and renders the appropriate template / layout.

Then there's all the other useful side classes Session, Cookie, HTML, Money and I haven't even got onto to Models yet.

Next time

I might have made a diagram to explain how this works, or myabe will be ranting about the Model parts, and multiple database access. To be honest to point of this article was not so much about the actual code, but more the structure and how if you break it down, a framework with much of the principles of Cake can be put together relatively easily. Of course I am only half way through, but progress has been quick.

In conclusion, I found it extremely interesting to see how the varous part of a framework work together and it is very satisfying to see it all fall into place. I now have the basis of a web-application framework that I understand inside out because I wrote every line of code. That is the benefit. When I use this now I will be supremely confident that I understand every nuance and feature.

As I had already written some articles (hard coded too...) I figured it would probably be a good idea to link to them directly. The first is an authentication plugin for CakePHP, DarkAuth.

I wrote DarkAuth as an alternative to the inbuilt "Auth" authentication system in CakePHP 1.2. I never really looked at "Auth" so cannot comment on how good it is. I can say that DarkAuth works for me and how I want it to.

"How I want it to."

That's right, how I want it to. It may be perfect for you, or it may just make your life difficult. That being said, let me walk you through the concepts, then give you the links to the article.

DarkAuth is designed around role-based authentication for actions. I call them "groups" in the tutorial but more often than not I consider them access roles. This means that if you are not using HABTM associations in your app, DarkAuth probably isn't for you. the exception to that is if you don't use groups at all, then it's probably quite good!

The other "feature" of DarkAuth is that you don't have to create a specific "login" URL. If auth is required by your app on a page and the current user is not authenticated then the login is automagically displayed. If the user is logged but doesn't have the correct "role" or "group" then the access denied page is shown instead.

It's quite clever really and allows you to do things like this:

So anyway, the reason you're reading this. The article and source code is on this website at /darkauth-1 and also at the bakery.

Hope you like it.