All posts

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.

Not an apocalyptic incident, just that my Japanese course has finished for the summer, which is a shame because I was enjoying it and now I have to keep that momentum up myself before they restart in October.

So, I thought I'd write something about it to encourage myself. Also if you live anywhere around Exeter (Devon, UK) then you should sign up at Exeter College, because we could use the numbers and Noriko's classes are excellent.

Learning Japanese

When we first started we were told about "how easy it is to learn Japanese" and some of the arguments are quite convincing. I studied Latin at school, which is about as complex as I thought a language could get. A lot of the things that surprised me about learning Japanese is just how different the structure of the language is to anything I had seen before (i.e. Romance and Germanic languages).

Why Japanese is easy to learn:

1. There's no articles (i.e. a book, or the book, just "book")
2. There's no gender or plural. Objects just are, they have no male/female/neuter preferences and the word for one is the word for many.
3. There's only 2 tenses, past or present/future.
4. Questions are formed form statements by simply adding the word "ka" at the end. No re-arranging of words / sentence structure.

Which was great and we're were all thinking how good this was going to be. Then we actually started learning...

Why Japanese is difficult to learn:

1. They have 4 differents character sets:
   • Romaji: Japanese transliterated into Roman characters
   • Hiragana: 46 symbols indicating sounds, some of which can be combined, and some of which can be accented, making about 100 sounds. These characters are used to write "Japanese origin" words.
   • Katakana: A different set of 46 symbols, as above, but used to write words of "non-Japanese origin".
   • Kanji: the pictograms adapted from Chinese that represent ideas, there are about 2000 standard Kanji, but many, many more exist.
2. The structure of the language is nothing like any language I have learnt. For example they have no verb "to have", so instead of saying: "I have this thing", they say "This thing exists" which doesn't really sound right to me and I can't get my head around it.
3. Verbs are strange. They have 4 basic forms, which I don't really understand at all.
   • the "dictionary" form is only used in a dictionary as far as I can tell.
   • the "-masu" form is a polite form
   • the "-tai" form indicates a want to do the action of the verb
   • the "-te" form indicates some other meaning, and is also used when using more than one verb in a sentence to "and" them together.

And there's probably some more I can't remember right now. Basically it means that learning is pretty hard for me. I like structure and rules. I leanr languages by understanding the grammar and I don't understand Japanese grammar.

This is by no means a critisism of our Sensei, she's been excellent, but because of the complexity and just how different it is, Japanese is not taught by grammar, but in a more fuzzy way, particularly to start with.

In turn this then means that I have been learning it for an academic year, yet can say very little, and cannot form anything but the most basic sentence, and only with predefined verbs. It's very frustatrating.

On the other hand, it is an absolute joy to be able to read and write in a brand new alphabet and learning hiragana and katakana has been very rewarding.

To aid my learning I fell back on my other skill, code, to create a web based Kana Test, to practice learning the Kana. Unfortunately, Julie, on our course completely obliterated any score I was able to manage and now reigns at the top of the scoreboard, no-one able to budge her off...

You can try it out if you want: Hiragana/Katakana Recognition Tests

Still, I am looking forward to continuing next year, and if I'm up to it, I might enter myself for a GCSE!

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...

I wanted to have a syntax highlighting facility for this site as I knew there would be plenty of code on here. First I just used PHP's highlight_string function, but soon realised it's drawbacks - not XHTML compliant, no line numbers, only works for PHP...

So I did a bit of Googling and found two major contenders, the PEAR::Package::Text_Highlighter library, and GeSHI. The PEAR one looks a little more complex and bulky, but GeSHI seemed perfect.

So I started playing with GeSHI and found it incredibly easy to get to grips with. The highlighting was very customiseable and it natively supported more languages than I would ever need.

The main issue I have with GeSHI was that it killed my lovely lined display. for some reason I couldn't get it to follow the lines. Eventually I realised that it was a Firefox / IE issue, with IE behaving and Firefox being odd (?!). I didn't see that one coming. However I found that by removing all of the inline styles and using CSS instead I managed to allieviate this issue.

Now I have the facility to syntax highlight code in any one of the 53 odd languages GeSHI supports. Pretty nice!

The next step was to integrate this with my existing CakePHP text-to-html converting helper. I created some new BBCode tags like [code syntax='javascript'] to make it easy.

Before I embraced frameworks, I created an AJAX Object that was lightweight, easy to use and efficient. I still find it very useful when making small, standalone, single-page type web-apps and certainly proved invaluable when I wasn't.

It's usage is very simple, first include the library:

Then define what you want to do and away:

The code is nice and efficient, killing and reusing the XMLHttpRequest Objects (or the ActiveX versions of them). So you don't need to worry about it at all.

The go function takes the follow options:

If things go wrong, you can debug the AJAX requests easily using the "debug" flag. It will then alert at various stages of the process allowing you to easily see what's going on. To enable, simply set Bjax.debug to true:

There's also included a really useful function prototype, which I took the idea from from the Prototype library. The prototype is bind and always you to bind functions to objects so that when the AJAX response comes back, you can call a function in the context you where in when it left off!

If you understood that last paragraph then you know how useful that is, if you didn't, then you will find that you need this functionality at some stage or other...

Anyway, the source is available here: bjax.js (3782B) or the minified version (with debugging removed) bjax.min.js (2406B)

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.

What an incredibly original title for this - my first post.

Well, I figured that it covered the main point of this entry, that is to introduce myself and this website. My name is Chris. I live near Exeter, Devon. I like to surf, am enjoying learning Japanese and am a bit of a techie. I enjoy building websites and learning the technologies behind them.

This blog is my second major attempt to keep my own website. The first, ModByChris.net, was OK, but not built to any rigorous design standards, had a poor lightbox effect for images and more importantly, I didn't update it nearly as frequently as I should have.

This time thing will be different! This time the pages will not be solely focussed around what I have been doing (i.e. personal diary type posts), and be more focussed around the technical side of things: experiements, tutorials and experiences. Thus these articles may actually end up being of some use to someone (?) and, if not even that, a good back-reference for me. That is not so say I won't post about how amazing the surf was last weekend, or some pictures of random events in my life (I may even build a simple gallery!), but they will probably be less common.

At least, this is plan now. Time shall tell how it happens...

I have been building this site over a fair while now, much longer than expected, due to the fact I have been trying to move house, jobs and organise a wedding all at once. But now it is here and I aim to write here at least once a week. The next step is to build a comments system so if anyone actually reads it, they can leave comments and there can be discussion.