Preamble: This is not a Kohana bug per sé, it affects all PHP applications that use cookies when viewed in certain browsers (particularly IE) and further reading can be found at on the PHP.net site. The first part of this post discusses the symptoms of the issue that are specific to Kohana but the solution will be relevant to all.

Background

For quite some time now, I have followed the naming convention

http://[site]_dev.[server].creativeintent.co.uk

for my development sites. It seemed a nice, simple (and obvious) way to differentiate between production and development sites on our servers.

We've been following this pattern for quite some time now without issue. Chrome is our browser of choice in the Creative Intent studio because it offers such a powerful range of tools to us during development. However, it would seem that our good friend has been holding our hand and leading us down a dangerous path by being just a little too helpful.

The Symptoms

The issue first cropped up at 0930 this morning after we'd presented initial access to a client for their ecommerce site which we have been developing. This particular client already runs a popular online shop on our CaffeineCommerce platform but shortly after emailing them their access details for the development site, we'd received a support request..."I can't login!".

We double checked the authentication process to the administration area from our desks and everything seemed fine. Cue nearly an hour of telephone support, "Are you sure that you're on the right domain, entering the right username and password...?", clearing caches, cookies and restarting computers and servers. No joy! So we moved onto debugging. Sure enough, the login details were correct and if I pasted them into my browser they worked!?

"Which browser are you using again?" ... "Internet Explorer" sigh

What's happening under the hood?

So, I booted up VirtualBox and opened a Windows XP VM, tested in Internet Explorer and sure enough the log in failed. However, opening the production site and logging in...no problem!

I am rather embarassed to say that it took me quite some time to understand quite what was happening here. The request was getting from my controller to the Auth module, successfully and the Auth module in turn was returning a positive result and saving the user into session. Great.

Next, the controller takes over and redirects the user into the administration area, only by this point the Auth module reports that we are no longer authenticated and redirects us back to the log in page BUT only in Internet Explorer!

What is this voodoo curse?

Everything is pointing towards a bug in the session management. There used to be a known issue in Kohana 2.3.X whereby some installations would regenrate the session on every page load. I don't think that anybody ever discovered why this happened but eventually the development team simply removed the automatic regeneration (2.3.4 onwords), leaving up the the developer to manage this manually. I'm using version 3.X so this can't be the problem, sure seems similar though.

So what else is different between the production site and the development site? Well there's an underscore in the server name part of the URL but that wouldn't cause the session to regenerate on every page load in Internet Explorer...surely? Would it? Yup.

Solution

Quite simply, the solution is to avoid the use of underscores in your server name where possible. The use of underscores in domain names is, in fact, not valid and although some browsers such as Chrome and Firefox will allow you to plough away without issue, there are still many browsers that will throw up unexpected errors that may take some time to debug.

Last Friday saw the release of the iPhone 4S in stores across the UK. I happened to be in town and spotted that the Vodafone shop on the High Street had the new handset in stock and so, I treated myself to a little impromptu upgrade!

What's impressed me most, so far, is the speed of the processor and how smoothly it runs the exciting iOS5. Having taken part in Apple's betas, running iOS5 on an old 3GS for the past few months, I'd gotten used to a rather disappointingly sluggish interface. But with the new handset comes a new lease of life, my iPhone is like a spring chicken.

And so, to Siri

If you aren't familiar with the new Siri concept that Apple have introduced to the the iPhone 4S, then check out the videos on the Apple website. The general concept is not new. Many companies have tried and ultimately failed to implement a voice controlled interface over the past few years.

Having played a little with Siri and having gauged opinion on the internet, it seems that Siri, in it's present format, is fun. A novelty. But not particularly useful...yet. Knowing Apple, Siri will not be left to rot. History has shown that Apple will release a product in it's basic form to generate hype and then over the coming months, a number of tweaks and additions will be made in order to maintain that level of excitement and chatter.

For UK users, many of Siri's more useful functions such as finding a business, calling up directions etc are met with a dull "I'm sorry Matt, this service is only available in the USA." As disappointing as this is, I'm sure that it'll be opened up to UK users shortly.

API hooks for third-party apps? 

What I'd like to believe is that Apple will provide API hooks to use developers so that we can hook Siri into our own apps. Its level of voice to text accuracy is impressive and I cannot imagine that it'd be massively difficult to open the service up to third-parties for use. I'll be keeping my eyes open for more news and keeping my fingers crossed that we might be able to operate the likes of UK Solar Survey and Invoice Agent by voice in the very near future!

Having spent a large part of this evening preparing the foundations for a large UX review that we're conducting, it struck me how mobile frameworks, such as Cocoa for iOS and the Android SDK, are setting an exciting precedent for user experience.

Over the past few months, I've had the pleasure to work with native iOS and Android projects. On returning to web based app development, it has struck me how none of the common frameworks seem to put an emphasis on encouraging even the most basic of UI hints that the mobile frameworks insist upon.

The most strikingly obvious omission from the majority of everyday applications is what Apple refers to as the 'first responder' and you've probably never considered it up until now. If you have an iPhone or Android device, then you'll notice that when you open an app that requires an action, maybe a log in, the first input field is selected and the keyboard is on screen ready to go. Simple, right? So now open up one of your favourite websites, or maybe one that you've built...does it readily select the field that you're most likely to want. With a few exceptions, probably not.

Why not? Well, the mobile frameworks encourage the developer to provide a first responder out of the box but, to my knowledge, no web frameworks do so. It's a very simple UI tweak to achieve with a little bit of JavaScript, the focus() function is perfect if you have jQuery at your disposal.

It's really quite surprising how such a seemingly trivial afterthought can make your web app seem much smoother and easy to use so think about adding it to your apps in the future. There are a number of other simple tricks that mobile apps bring to the table that could help to improve usability of your web app too but maybe I'll talk about them in a later post.