All posts tagged "CakePHP"

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.

I found another small glitch in DarkAuth, which stemmed from the major bug after CakePHP 1.2 RC1 was released.

The Controller::render() method has changed, which was integral to DarkAuth's functionality. The change stopped anything from being displayed if Auth was not present or sufficient. To fix it I had to force an exit() into the code.

This exit() then meant that the Component was not setting the $_DarkAuth variable at all, if the "login" or "deny" view where being displayed.

The updated code fixes this, and has been updated on the DarkAuth page.

In addition I introduced a nice utility method, DarkAuthComponent::getUserId() which simply the returns the id of the currently auth'd user. Something I needed often.

Also I decided it would be good to have a "test application", a simple setup of a working DarkAuth + Cake combo. So I have built one, and you can use it to see how DarkAuth works, and to play around with it to your hearts content!

There's 2 versions: one is just the app/ folder, and the other contains the full CakePHP1.2 RC1 code as well:

• DarkAuth.test.app.zip just app/ folder
• DarkAuth.test.inc.cake.zip full example Awaiting Update...

I put some useful code in there to help create the database config file and set up the required tables, so just extract and play!

I have recently updated the code in /darkauth-2 to be compliant with the newly released CakePHP 1.2 RC. Only a small fix, but it made me think about DarkAuth and how it works best.

When I originally wrote it, I recieved some feedback from several different sources syaing that it was difficult to understand and didn't necessarily work as expected.

This was because DarkAuth has a very specific methodology and and is just as much an Access Control component as an Authentication one.

Authentication and Access Control

• Authentication is a method of identifying users.
• Access Control is a method of restricting those user to what they are allowed to do.

DarkAuth has some useful functions that help with both. In the next release of the code I intend to rename all references to "Group" with "Role" as it is really about Role-Based Access Control.

In my usual setup for using DarkAuth I create 5 tables: users, roles, roles_users, groups, groups_roles

The first three are straight forwards, they define the users of the system, any roles that might exist (think roles like "CanAddPosts", "CanEditItems", etc...) and the join table that defines their relationship.

The next two is where I define Groups of Roles. The whole point of this is simply a helper - I can pick which roles I give to my users explicitly, or I can choose a group which contains a certain array of roles. It just makes it easier to manage. Enough talk, on to an example.

Let's see it it action...

Using the following tables:

And with some sample data:

Which creates a mapping of roles to groups. We can then create a function which applies the given set of roles to the user. I put mine in GroupsController for lack of a better place, but I am not sure it should stay there. It goes like this:

This function will then allow you to align your users' access to fit all the roles you have associated with the group.

This brings a question, should I links my groups with users directly? and read their security roles from the group. Or do I simply use the groups to define set of roles to Apply to users as I want?

I don't know.

The first sounds better, but then we couldn't do any bespoke customisations (i.e. one-off adding of roles to particular users). The second is what I currently use, but if you update a group the use's dont' automatically update.

I guess there's an answer in there that you update all users' permission's that match the previous role set of a group to the new role set whenever you change a group. Confused? hopefully not too much...

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.