A quick click of the widget will allow you to submit ideas, a question, a problem or give me some head-bloating praise. Feel free to use and abuse but remember this is a public means of communication, if you need to contact me privately you can always email at webmaster@michaelwales.com.

Edit:
Chris Harrison pointed out Skribit to me and it is much better suited for this purpose.

Last week, on the Official Google Enterprise Blog, the Senior Product Manager of Google Apps announced that as early as March 2010 Google will start phasing out support for older browsers. The official lineup Google recommends consists of Internet Explorer 7.0+, Mozilla Firefox 3.0+, Google Chrome 4.0+ and Safari 3.0+.

Google also sent an email to all Google Apps for Domains administrators yesterday that clarified some concerns people had: this isn’t just for the enterprise users. Users of the standard GMail and Google Calendar will see functionality dropping off on older browsers as well. This really shouldn’t come as a surprise. As developers, would you expect Google to maintain two separate codebases, one of which has inherent flaws that consistently introduces security vulnerabilities? I didn’t think so…

Is this the nail in the coffin that is Internet Explorer 6? I think so! With such a drastic change from one of the industry leaders, a company most people couldn’t dream of living without in this day, older browsers have no choice but to die off. Most people using IE6, or various other older browsers, aren’t doing so by choice – they are in enterprise environments in which they are not able to upgrade. These companies are now being told by one of the largest providers of software they use on a daily basis, the time is now! If more companies, and even developers like us, took a stand like Google is we would see an end to the 8+ year browser lifecycle that IE6 has enjoyed.

In November 2007 I released an authentication library for CodeIgniter named ErkanaAuth. It was very simple to use since it just provided a few methods to make authentication simpler for you – it didn’t hijack the entire process. The post announcing that library, and the code, has long since been lost but you can still read the original post thanks to Archive.org’s Wayback machine.

Recently, I’ve taken on a personal project of a rather grand-scale and have started factoring out the authentication logic into a library of it’s own, which I am referring to as ErkanaAuth 2.0. I am now releasing the library in its current state which is vastly unfinished! Nonetheless, I would love to hear your thoughts on the direction the library is headed and features you would like to see.

I don’t think I can reiterate this enough at this point in time, this is hardcore alpha – I should have called this ErkanaAuth Version 2.0ha-dont-fucking-use-me-in-production-code. I mean, in theory you could use this, and if its a library you want to use in future applications I strongly encourage you to give it a go. The authentication mechanism is secure but the library as a whole is sorely lacking in features at this point and is pretty hard-coded to a strict environment.

Features

• Authentication via username or email address and password.
• Account creation using username or email address as unique identifier.
• Locking of controllers/methods to logged-in users in one line.
• Passwords are hashed with a salt prior to storing in the database.
• User token stored in session is a hashed representation of the user’s ID and their password hash. Encrypting the session cookie via CodeIgniter’s config/config.php file adds another layer of security against altered session data.

Planned Features

• Exponential delay on failed login attempts.
• Group-based authorization system.
• Require email validation on account creation.
• Optional Captcha on account creation.
• Linking of Facebook / Twitter authentication to Erkana Auth Account.
• Forgotten password resets.
• Extensive account API for building of authentication administration panels.
• Extensive group API for building of authorization administration panels.

Installation

The downloadable package includes a number of directories and files within those directories. It is advised to extract the archive in a temporary location, ensure there are no naming conflicts with your current application and then move the directories into your CodeIgniter application’s directory. The most common naming conflict will be with the models/account.php file. The list of files included are:

• helpers/erkana_auth_helper.php
• language/english/erkana_auth_lang.php
• libraries/Erkana_auth.php
• models/account.php
• sql/1-create_accounts_email.sql
• sql/1-create_accounts_username.sql

After installing the library within your application directory you must decide whether your application will authenticate based on username/password or email/password and run the correct SQL file on your database schema. This file will create a table named accounts, the statement run by sql/1-create_accounts_email.sql is:

If you run sql/1-create_accounts_username.sql the following statement will be executed:

Usage

ErkanaAuth aims to be as simple as possible in its usage. As of this version, this is primarily due to the limited scope of its functionality, but the overall feel for the library will differ as little as possible from what can be seen as of now. Many of the limitations on the library (i.e., strict naming of form fields) will be corrected as development continues.

ErkanaAuth does not assist in the creation of any front-end related code (i.e., user registration forms, login forms) at this time. ErkanaAuth simply provides a powerful set of methods to be used within your controllers to assist in getting an authentication system up and running as quickly as possible. Additionally, there is a helper function to display useful error messages to your users for invalid form submissions.

Creating a User

The create_account() method accepts a single string parameter of either email (default) or username, which should reflect the authentication mechanism you opted for during the installation and execution of the SQL file earlier. This method will return TRUE or FALSE if the user was created and can be used similarly as to how the standard form_validation library is used.

The library currently requires the following form fields to be present with the corresponding rulesets:

• email: Only if you select the email authentication mechanism (required|max_length[120]|valid_email|trim)
• username: Only if you select the username authentication mechanism (required|min_length[4]|max_length[20]|trim)
• password: Always required (required|matches[passwordconf])
• passwordconf: Always required (required)

The controller method that displays and processes your account creation form should call the create_account() method and redirect on TRUE, otherwise loading the view file that contains your account creation form. In the following example, the user is redirected to accounts/index() which would display our login form.

Validating a User’s Login Credentials

The validate_login() method accepts a single string parameter of either email (default) or username, which should reflect the authentication mechanism you opted for during the installation and execution of the SQL file earlier. This method will return TRUE or FALSE if the credentials are valid and can be used similarly as to how the standard form_validation library is used.

The library currently requires the following form fields to be present:

• email: Only if you select the email authentication mechanism
• username: Only if you select the username authentication mechanism
• password: Always required

The controller method that displays and processes your login form should call the validate_login() method and redirect on TRUE, otherwise loading the view file that contains your login form. In the following example, the user is redirected to announcements/index() which would display a “dashboard” like page and only be accessible to logged in users.

Validating a User’s Logged-in Status at Page Load

The required() method provides a simple, one-line, way to validate a user’s session and ensure the user is logged into a valid account. This line should be placed within the constructor of any controller class you would like to complete protect or as the first line of a method you would like to protect. The following example is a controller named Announcements that currently only has its index() method protected. Any other methods added to this controller would not be protected without either moving the required() method to the constructor or placing a call to the required() method within the controller methods themselves.

Displaying Errors on Invalid Form Submissions

The library includes a helper with the function authentication_errors() to assist in displaying errors upon form submission. This function will return all errors, delimited by a
. If there are no errors, NULL is returned. In the following example, we are displaying a login form that will display errors at the top of the form if any exist from prior submission attempts:

Technical Details

During account creation an alphanumeric string is randomly generated to serve as the user’s salt. This salt is then hashed with the user’s password and the resulting hash is stored in the database to validate against.

On a login attempt, the database is queried for a record based on your authentication mechanism (email or username). That record is then compared against the user submitted data for validation. On a successful validation, session variables are stored consisting of the record’s id and a hash of the record’s id field and password_hash field.

When a user visits a protected page the session is first checked for the variables that are set by a successful login. If these session variables exist, the database is queried for the record identified. If this record exists, the session is further validated by comparing the stored hash of the record’s id and password_hash with the data that is stored in the record.

Download

Erkana Auth 2.0a is available for download. At this early stage of development a version control repository has not been made publicly available. In the future, Subversion and Git repositories will be made available.

License

ErkanaAuth 2.0a is licensed under the BSD License as defined by the Human-Readable Creative Commons Deed.

This book targets the absolute beginner developer and it does an adequate job filling the niche, as previous CodeIgniter books on the market are drastically outdated. Unfortunately, I don’t feel this book differentiates itself significantly from the well-written CodeIgniter User Guide and many people who buy this book will feel as if they have been cheated out of $36.

Chapters 1-3 explain what frameworks are, what CodeIgniter can do for you, how to get up and running with CodeIgniter and the basics of the MVC development pattern. It’s not until Chapter 4 that we discover some truly unique CodeIgniter content with the Active Record pattern, but it doesn’t last as we drop back to some pretty basic HTML material in Chapter 5 as we build out some forms.

The rest of the book does a very good job of reiterating the content outlined in the user guide, ranging from sessions and security to the XML-RPC library. There’s even a bit of content on the Cart library which is a welcome addition since it’s relatively new.

The shining star for this book though is Chapter 7, CodeIgniter and Objects. Argudo and Upton do an amazing job describing the CodeIgniter super-global object, as well as explaining copying by reference in plain English. Unfortunately, it just kind of creeps up on you out of nowhere with very little lead in or warning that shit’s about to get deep. It’s a worthy addition to the book though and serves its purpose in separating the “restating the easy stuff from the user guide” from the “restating the object oriented stuff from the user guide” sections of the book.

All in all, if you feel as if you need the user guide read off to you in plain English, by all means buy this book. There’s nothing else on the market today that will explain virtually every aspect of the framework to you as a beginner. If you’re comfortable in reading and understanding the user guide, possibly with a bit of help from the CodeIgniter Forums, you’re going to want to pass.

Last but not least, this is one of the few books whose eBook version actually provides a legitimate value (other than just being a good option for the broke audience). If you fall between the two aforementioned groups (i.e., you are comfortable with the user guide but you don’t quite understand the CodeIgniter object model or how to best write your own libraries) buy the eBook now. You’re going to save some money and Chapters 7-9 and 15 are well worth the $28 price tag.

HipHop PHP is essentially a compiler (although Facebook calls it a transformer) from PHP to C++. Only a subset of PHP functionality is compatible with the compiler but the developers say they only omitted some of the lesser used functions like eval(). The C++ code is truly cross-platform and can be compiled and run on virtually any server, the primary benefit being decreased CPU usage and therefore increased speed when delivering content to the end-user.

So, what does this mean for the CodeIgniter community? In short, absolutely nothing. Most CodeIgniter developers are building applications that will run on shared hosts, virtual private servers or a cloud-based virtualization system. Of that very large group of our community, an extremely small number have the capability to compile the HipHop binaries or alter their configuration in order to serve HipHop pages.

There are a very small number of CodeIgniter applications that are running on a couple of dedicated servers. Even these developers have no need for HipHop! The performance benefits gained by running HipHop on these server would be marginal at best, if even noticeable. These sites just don’t have the traffic to see measurable gains in performance by focusing on CPU usage. Their time is much better spent focusing on the standard bottleneck: input/output (database queries and caching of output).

It wasn’t until two years ago Facebook had enough traffic to make optimizing CPU usage a worthwhile focus of developer time. Compete won’t let me go back and look at traffic two years ago but I think the graph above speaks for itself: Facebook has more than doubled its monthly unique visitors in the past year. Most of us will be lucky to see .01% of that traffic on our applications (to put it more in perspective, codeigniter.com currently received .03% the traffic Facebook does).

In the past I have tried to get some really nice themes up here thinking it would encourage me to write and share more. I’ve come to realize that’s just not true, so I will be sticking with the tried and true Simpla theme. It gives me plenty of width in the primary column to share code and that’s my goal from here on out – share code.

I’ve got freelance projects, a full-time job, a book deal, and a family up to my ears – no more trying to market myself as a freelance developer. I’ve succeeded there beyond my wildest dreams and I have to thank more of you than I can possibly name for that. From here on out, I’m going to try and improve your code – make you a better developer.

Hang in there with me – I’m pretty excited about trimming the fat and really getting deep in the content here. Better hold your watches up…