Monday, 12 November 2012

Break MySQL formatted datetime

Well it has been MASSIVELY to long since I last posted anything here. I do have lots of plans on other posts to write, it's just finding the time. Now that the rock climbing session is over I'll hopefully be able to write more here.

So along side the PHP secure login class I'm making a utilities class (only just started) which will have just some generally useful methods. It's not a unified class so the methods in it can easily be copied out and put into another class or just as a plain old function.

Currently the only method I've added is one to break apart a MySQL datetime string into an array so you can display it in a different order to your users easily. I do have others made to add but they require a little more testing first.

Here is a link to the Google Code site which I just made so there's not much on it, just this method in a class and a short description of the class.

The only part which I've copied from someone else is the regular expression which validates the MySQL datetime string, I just don't understand regular expressions well enough to write my own of check this one but so far in my testing it seems to have worked. If you know something I don't feel free to leave a comment or get in contact with me!

Tuesday, 24 July 2012

Quick update


As I haven't posted in a while I thought I'd let everyone know I'm still keeping this blog active, just getting a bit busy at the moment.

Currently the project I'm working on will probably involve 'retrofitting' responsive design to site designed for desktop usage (not ideal) and I'll be posting about that in the coming weeks. It'll also involve print stylesheets so I'll complete and expand on what I've written in a previous post which was meant to be a multi-part series but I haven't had the time to finish it, but I will.

EDIT - 16/01/2013
Thought I should mention that the retrofitting of a responsive design project never went ahead so I haven't written about it.

Tuesday, 10 July 2012

Multi byte safe coding

Again sorry it's been a little while since I posted (this seems to happen a lot) but I've been quite busy at work on my PHP login script, building a few client sites and learning After Effects for more client work.

This post is all about multi byte characters and how to write your code so it can handle them, which for the most part isn't to hard in PHP. Everything I'm writing in this post is based around UTF-8 but I believe it'll be applicable to some other types of encoding, worth looking up for yourselves though if it's important to you as there are far to many types of encoding for me to look into.

What is a multi byte character?
A multi byte character is basically what it sounds like, a single character which takes up more than one byte of space. To explain that a bit better, if you had a plain text file and save it with only one English letter in it'll use up 1 byte of space on the hard drive, every character in the English language and numeric system is the same.

Now this isn't the same for all languages in the world for example a fair few Chinese characters and even some mathematical symbols among quite a few others will use more than one byte of space to represent them.

Do you need to worry about being multi byte safe?
It all depends on your site / application and if you think it'll need to handle multi byte data or not, personally I'm thinking I may start to write & rewrite all my generic classes which I use or intend to use in many other places to be multi byte safe; my secure PHP login is going to be a good place to start.

As far as I can tell there isn't a down side to using it but I haven't personally done any performance testing yet, I can't find anything online that says it has a downside though. If you find something different please leave a comment.

Little bit of extra info
I've put a link to the site which lists all the PHP functions that have multi byte equivalent functions but also the standard explode & str_replace functions are multi byte safe as far as I can tell.

Further information

Wednesday, 27 June 2012

Detecting PHP versions

This is a quick post about detecting what version of PHP your server is currently running, why would this be important? Well there are quite a few PHP functions which only work from a certain version onwards or work different from one version to the next. I encountered this while making a few amends to the way sessions are regenerated in the secure PHP login class I've been building with the session_regenerate_id() function.

How to detect versions

There is more than one way to do this but I'm just going to cover the method which will work in PHP 4 & 5 and tell you exactly which version is being used. The code is below:

if(strnatcmp(phpversion(), '5.0.0') >= 0)
echo '5 or higher';
echo '4 or lower';

The strnatcmp() function compares two strings to each other using a more 'natural' human method rather than the way computers would normally do. For example a computer would normally put the number "11" before the number "2" but using strnatcmp() it realises an eleven is an eleven and not two ones next to each other.

phpversion() does pretty much what it says, it gets the PHP version in use on the server. It does have a parameter which you can pass to it which I think is to do with finding out about extensions (or their versions) installed on the server. I can't say for certain about that parameter though as I didn't really look into it, it's not relevant to finding out which version of PHP you're using though.

Alternative method

I thought I'd briefly put this down, you can use PHP_MAJOR_VERSION to get the major version in use (5, 6 etc), PHP_MINOR_VERSION which gets the minor version and then PHP_RELEASE_VERSION to get the release. These only work from PHP 5.2.7 upwards though which is why I'm mentioning it at the end so you know it for future reference but I don't think it is very useful at the moment.

To understand the version numbers a bit better think of it like this, when you see a PHP version release it is normally something like 5.2.3. The first number is the major version, the second is the minor version and the third is the release, I won't cover what these all really mean here as it's not really relevant to this post.

Further reading

Monday, 18 June 2012

Almost done! (Version 1 anyway)

It's been a while since I did anything on this project but recently I have been doing stuff and it is so close to version 1 (see the wiki about page on this project) being finished. All that is left to do is testing which I started earlier today while implementing in on a client website, found a few small bugs and thought of a couple of things to add to this version.

What I've done recently

There have been various bug fixes (see the change log for more specifics) I've also added a logout method to the class but all it does is unset a test cookie to test that the user has cookies enabled and destroys the session.

The other bit I've added it is the ability to have an authentication field in the database which can be set to either 1 (authenticated) or 0 (not authenticated) for each user. I added this so if you send a confirmation email out to the user with a link to click which activates their account (a good idea to stop other people signing up with another persons email) then this login class will use that field now, this is optional.

What else to do

The documentation for this project is a little out of date now so before I say it is fully finished I'll be updating that too, the code commenting though has been kept to to date with every change made.

Further reading

Wednesday, 13 June 2012

What to consider in your print styles (you have one right?)

It's been a while since I last made a post but I have been doing quite a bit of research when I can into print style sheets, not something a lot of developers & designer consider when making a website (you can tell by just trying to print some random sites on the web). There are many articles out there which cover parts of this topic but I thought I'd write my own based on what I've read and generally learnt.

I'll write about two or three posts on this subject, this post is going to focus on what to think about when making a print style sheet and why you need one anyway. The next post(s) will give more practical information on how to implement different ideas and techniques.

Why have a print style sheet anyway?

Quite a few people like printing out websites, as surprising as this will come to a lot of people, particularly articles of long text, why would they do that? Some times it is because reading from paper is a lot easier on your eyes than off a screen which I think is in part due to screens only being 72dpi but printed is much higher. This of course isn't the only reason, sometimes people print out tutorials so they can follow along on screen without having to switch between windows (not everyone has large or multiple monitors like most developers), photos get printed from the web, to allow them to read an article while on the train as not everyone has tablet computers yet or pretty much any other number of reasons.

Size restrictions

One of the the main things to consider is the size restrictions of paper, I personally think it is safe to assume it'll be printed out on A4 paper and use that as a guideline of the space you have to work with. So if you have two columns of text (normally one main and a sidebar) if the sidebar is actually important and provides supporting content you might have to resize the columns or move them totally so they run one after the other to fit things in comfortably.

When making these decisions be sure to take into account the type of content on the page, for example is it an article of text, table of data, grid of photos or something else? If it was a table of data having content in two columns may not work out well as it'd squash the data table and make it harder to read but a grid of photos could benefit from having a few columns, as that basically makes a grid.

Another thing which must be done to make best use of space and of your users ink is to remove and elements of a page which aren't useful when printed out. For example the navigation of your website isn't going to help anyone when it is on paper as they can't click anything, keeping the URL to the pages on the paper is a good idea so readers can get back to the online page but most modern browser do this automatically anyway. If you wanted to go a bit further with the page URLs providing a shortened URL would make it a lot easier for them to type in, possibly even a QR code?

Other elements worth removing in general could be the header and footer sections, non-relevant images and sidebars which aren't providing any directly related information. The main thing to do is think about what on your site is going to be useful when printed out and remove the bits that aren't as what is and is not relevant can vary greatly from site to site.

What to print

Another consideration is what will the user want to print? It might not always be the whole website, for example I've been working on a climbing club website (not really print friendly yet, but will be soon) has a page of all the meets taking place through out the year. With a large list of meets it could be useful to print out information specific to one meet only (the one they are attending) and this is something I'll be implementing later this year on that site.

Of course if you decide users will probably only want to print part of the information on a website you need to think of a method to show the user only the content that will be printed so they know they won't print the whole page and exactly what will be printed. This is something I'll cover in another post (not in this 'series') once I've decided how to do it on my climbing clubs website and worked out some of the usability and practical issues.


Obviously these are useless on paper but printing out the URLs so that the user can type them in to the browser (or as mentioned above providing short URLs or QR codes) can be done giving the user the ability to still make some use of those links. I'll be covering this in one of the next posts.

I'd also say that leaving links unstyled and just looking like the rest of the text is probably the way to go as link are useless offline in a printed form. I did read an article that stated it would be good to leave them styled so the user could see where links were and then view them on the online version but I cannot see why or how this could be useful.

A thank you message

I've read this in a few places that adding a thank you message some where to thank the user for printing off your page is good. Personally I can't see how it's useful or why you'd want to thank people who have printed it out and not the people who viewed it online. I just thought I'd mention it as a few articles mention this so maybe I'm missing something and just can't see the reason why you'd want this.

Wednesday, 16 May 2012

External links & new tabs: The conclusion

It's been a while since I last made a post, sorry about that but I just seem to get to busy to research things I want to post about (I have fair sized list though). I have recently come to a conclusion about opening links to external websites and that is what this post is all about.

What am I actually talking about?

Well a little while ago I posted about external links on websites and if they should automatically open a new tab or if they should open in the same tab by default and allow the user to decide what they'd prefer.

So, what is my decision?

Personally I have come to a conclusion and it's actually quite a hard one despite seeming like such a simple thing. The way I see it some users are going to expect a new tab to open, others will get annoyed by it, others still will just get confused by it and wonder why the back button doesn't work and just close the whole browser as they don't really understand the whole tabbed browsing.

So what to do? Well I think in an ideal world you'd perform some user testing on the target audience for the website. However if that is not an option due to budget restraints or for any other reason I'm going to 'default' to opening in the same tab and using the symbol which seems to have taken off a little to indicate a link goes to an external site. Along with this I'll add into the link title that the links goes to an external site and the user can decide about opening in a new tab.

Why did I decide this?

The main reason is I think any of the options you could pick from can annoy or even confuse users but by letting the user have control and use their browser how they like seems like the right thing to do and is a fairly good usability guideline which I think applies here. As more and more people (normally younger people who've never used browsers without tabs) seem to get bothered about new tabs automatically opened.

Will my sites lose users?

One of the arguments for opening links in a new tab by default is that if they all open in the same tab you'll be directing users away from your website and as such losing them. Personally I don't think this is true, if the users wanted to be on your site they're more than capable of navigating back there and I'll make the assumption you are not linking out to a competitors website but a site with more information or is otherwise useful to the user in which case after finding out what they wanted they'd return to your site if it had something of value to them.

I'm sure someone has come up with a statistic that opening links in another tab retains your user for longer (I'm sure I've seen it but can't find it any more) but I think it's a bit of a falsehood. Although the user will still be on your site they'll actually be looking at another and yours just happens to be open at the same time, not as useful as getting users to return to your site because it has value and they want to be there.

If anything I think allowing users to decide if an external site should open in a new tab or not will retain users as the more knowledgeable users who understand browser tabs can choose to use it and the ones who don't but are used to using the back button get to use it by default rather than using a potentially confusing tab system.


I'm basing this all off of my own experience and watching people using browsers as well as reading other sources of peoples opinions whom I respect, this isn't based on any empirical data but hopefully one day someone will do a study and I'll come across the findings.

Update - 17/01/2013

I've felt it important to add a little more to this, just that WCAG 2.0 also supports my conclusions I felt that it's important to note as I've missed it out so far and the people who came up with WCAG 2.0 have put a lot of time and research into what they write. I'm also aware that it's come under some 'attack' for being basically being to big but I feel from what I've read so far the content it self is all sound.

Monday, 16 April 2012

Why your canvas paths could be to wide

This is a quick tip about drawing paths on the HTML5 canvas element and why your lines maybe wider than you wanted them, it's all to do with the fact that you can't draw a half pixel.

What's the problem?

To draw a line on a HTML5 canvas you first tell it where to start using context.moveTo(x, y); then tell it where to end using context.lineTo(x, y); and afterwards set it's colour and stroke properties. The problem is that HTML5 canvas draws a line at an equal width either side of those defined points, but if you want a 1 pixel thick line and define its start and end points as being a whole number then it would need to draw a line 0.5 pixels either side of that point to create a 1 pixel line. As it cannot draw half a pixel it will instead be forced to draw a whole pixel either side of the start point and create a 2 pixel wide line instead of the 1 pixel line you wanted.

The solution

The solution is quite simple, instead of defining your start and end points as whole pixels define them as a half pixel, and example of the correct method and incorrect method of drawing a 1 pixel thick, black 100 pixel long line is below.

Incorrect example

context.moveTo(1, 1);
context.lineTo(1, 100);
context.strokeStyle = "#000000";

Correct example

context.moveTo(1.5, 1);
context.lineTo(1, 100);
context.strokeStyle = "#000000";

Further reading

Wednesday, 11 April 2012

Lack of posts


I just thought I'd explain a little about why I haven't posted in a little white, I'm planning on switching away from Blogger to Wordpress as I want to integrate this more with my portfolio site (once it is built) and add more to this such as a dedicated area for my secure PHP login project and articles about web development.

I should hopefully have part of the switch done by the end of the weekend, enough so that the basic structure of the site is done (not necessarily the overall design) and the fact that it'll be running on Wordpress so I can continue posting again. I've got a few posts written up just waiting for you all to read.

Tuesday, 27 March 2012

HTML5 Structural tags


I thought I'd write a post about using HTML5 structural tags, not quite as fancy or impressive as the canvas stuff but there aren't that many talking about the structural tags which in the future we'll all hopefully be using.

I'm only giving a brief overview here, the links at the bottom explain it much more, although they do require more time to read.

What does it mean to be semantic?

Being semantic in the context for web development means using tags that describe what is contained within them, for example I'm sure you all place paragraphs of text inside of <p></p> tags as it's a paragraph.  If you wanted to you could place them inside of <li></li> tags and styled the appropriately to look like paragraphs, this would work and would even pass the W3C validator fine but wouldn't be very semantic.

What is a structural tag?

Basically tags which you use to semantically divide up your pages into different parts, currently we're all using div tags and giving them ids & classes to divide up our pages but this isn't very semantic.  I've listed the new structural tags that have been introduced in HTML 5 below:
  • <!doctype>
  • <article></article>
  • <section></section> 
  • <aside></aside>
  • <nav></nav> 
  • <header></header> 
  • <footer></footer>


This is used to let the browser know how it should parse the documents contents, for example it could state the document is a XHTML 1.0 strict document but there are so many different doctypes and they are so long no one can remember them.

HTML5 simplifies this by using just one doctype <!doctype html> which is something that everyone can remember and it doesn't matter if it is strict, transitional or anything else, an HTML document will always have that doctype in HTML5 onwards.


This defines a section (funnily enough) of related elements, for example you might keep all the references at the bottom of the pages in a <section></section>.  This is different to the <div></div> tag (which is not being replaced) as these are still used to divide content, for example in a reference section of your site you may have it divided into online and offline references.


This is a block of content which doesn't depend on the rest of the site to give it any context or meaning, in other words (as that might not have made a sense to everyone) if you were to copy that text out  of the site into another document, like an RSS feed, it would still make perfect sense and mean the same as it did before.


This tag should contain information and elements that are not directly related to the content around it but are loosely related to it.  For example if you had an article about HTML5 you may have an aside which links to other relevant articles you've written if it was a multi-part series or pull out for quotes from the main article.


This tag is pretty self explanatory, it is where you place major navigational elements for your page but you aren't restricted to using it only in once place.  You can use it for the top level main navigation and a secondary sub navigation or even for footer links too but most of the time just using the <footer></footer> tags for the footer navigation would be enough.


This contains elements that are at the top in the 'header' section of your page, normally <h1> to <h6> tags are in here along with any logos and slogans the site has.  This tag isn't only restricted to the heading section of a page though, it is also used else where inside any other <article> or <section> tags to define their headings.  An example of this would be if you had an article about gardening at the top inside the <article></article> tag you'd place the <header></header> tag and inside there place the articles heading tag(s), date it was posted and authors name.


This works much like you'd expect and you use it to mark-up the bottom 'footer' section of your page, quite often this will contain a list of links to pages on the site and this list can be inside of a <nav></nav> tag.  Much like the <header></header> tag this isn't restricted to just defining the footer of a page but also the footer section of an article or section.

Further reading

Tuesday, 20 March 2012

It's been a while

This is just a quick post to say that I haven't stopped blogging but the past two weeks I have had to work quite late and not had time to finish my latest blog post on HTML5 structural tags (now written).  It's about half done and either today or tomorrow I'll be posting it!

Again sorry for taking so long about getting my next post out!

Tuesday, 28 February 2012

External links & new tabs

This is something I've been reading up on quite a it lately, should links to external websites open in a new tab or not?  There's quite a lot of posts about this already and it is an issue which divides people a lot.

Why open links in new tabs?
New tabs keep users on my site
Some people think that opening an external link in a new tab means that you are giving the user access to an external resource but at the same time they are staying on your website and you're not losing a user / potential client.

I think this line of thinking is flawed, if the user doesn't want to be on your website any longer then they'll just leave anyway and if they did want to be on your site they'd just open links in a new tab or use the browser back button to return to your site.  A common example of this would be a person looking for some information, if you're site has it they'll read it and possibly bookmark it then move on as there won't be any reason to stay, if it didn't have what they wanted then there's no reason for them to be there in the first place.

A new tab is what users expect
This argument I think does have some credibility as I stated above a lot of people think opening a new tab or window will keep users on their site and as such have decided to implement this and have created user expectations.  On the other hand though there are a large number of sites which don't do this and I think the two methods often confuse users and they're not sure what to expect so I'm not sure if most users do actually expect external links to open in a new tab any more.

I have noticed in my personally browsing that more sites are moving to opening in the same tab rather than a new one.  This isn't any thing I can back up with data or references, just something I've noticed and might not actually be true across the web as a whole.

Users should decide
Firstly as a user interface designer you are trying to give the user the best experience they can have using your site, one of the best way of doing this is to give them control.  I don't think they should be given control over every part of your site but the basic browsing behaviour they experience no matter which site they are on such as opening links and using the back & forward buttons they should.  This allows them the option of opening links in new tabs or the same tab, when a user comes to your site they may already have a lot of tabs open and not want another and as such prefer to open the link in the same tab and use their back button.  This is just one example but overall giving the user control in this area will almost always give them the best experience in my opinion.

Even if you really feel that opening the link in a new tab by default is a must because you really think it will keep people on your site in a positive way, you can't.  There's always way around it such as copying the link and pasting it into the address bar or just dragging it into the address bar, although a lot of probably users won't know about these methods all you succeeded in doing to them is annoying them as they cannot do what they wanted.  Is that the kind of experience you want users to have on your site and how you want them to remember it?

Don't forget using the back button isn't that hard for the user and almost all web users know how to use it (the ones who don't probably don't understand what tabs are either).  In modern browsers you even get a drop down from the back button showing a list of previous site they've visited so they won't even need to click it multiple times to find your site again.

Should I never open new tabs & windows?
I wouldn't say it should never be done because it can be useful in the right circumstance.  For example opening PDF documents or large images as both can take some time to load opening it in a new tab or window and allowing the user to continue on your site is useful.  Another example would be on a form or shopping area of a site opening any help facilities that might be associated with it in a new window so they don't lose their data and can view both the help and shopping basket at the same time could be useful.

If you are going to open a new window or tab when the user clicks a link you must make the user aware that this will happen, for example providing a little icon next to the link & stating in the title text of the link that a new window will open.

My opinion
Although this whole post is based around my opinion I have tried to include a few other perspectives a little, I always used to think that clicking a link to an external site should open a new tab or window and you might have noticed on this blog a lot of them do.  When I actually put some thought into it I start to think that this might not be the best method and it would be better to let users decide.  Once I've fully decided which is best I'll change all the links on this site to match what I think but I think I'm going to let you users decide.

Further reading

Thursday, 23 February 2012

HTML5 Canvas 3d?

A few people seem a little confused by the HTML5 canvas tag and if it's possible to create 3d elements inside of it, the main reason for this is the getContext("2d") method with the parameter of 2d and logically people think there must be a 3d parameter too.

Is canvas 3d then?
Unfortunately there is only a 2d parameter for the getContext() method and no 3d option but in the future they are planning on adding the 3d parameter.

So I can't use 3d in canvas? :(
Despite what I've stated above it is still possible to have 3d effects using HTML5 canvas but it's just not been standardised by anyone yet, this hasn't stopped browsers from implementing their own methods of 3d.  The main method of doing this seems to be by using WebGL and there are a few HTML5 3d engines / frameworks out already based on this.

Unfortunately I don't really understand enough about the topic to go into any real depth but there are plenty of great examples if you Google around for them.

Should you use it?
Personally I wouldn't build anything that relied on it as only a few browser support it and as it's not standardised so in a few years when a standard does come out parts of what you've made may not work any more.  Personally I plan on building some cool web apps with it in the near future but mainly for the 'cool' factor.

WebGL security
I feel I should mention a bit about security in relation to WebGL in that it has some flaws, can't say I full understand these yet myself either but I've put some links below about them.
Further reading

Tuesday, 14 February 2012

What are CSS em sizes?

I thought I'd write a short post about CSS em sizes covering what they are and how to use them, I have just thought recently they're not all that easy to understand without reading about it somewhere which is what's caused me to write this post.

What is an em?
It's a flexible unit of size used in CSS mainly for defining the size of a font, what do I mean by flexible?  Well it changes relative to the font size of its parent, kind of like a pixels size is relative to the DPI settings if that helps.

For example if you had a document with a default text size of 16 pixels (the default for most modern browsers) then 1em = 16px, if the default was 10 pixels then 1em = 10px.  This only changes if the parent has a different font size set, for example if a document has a default font size of 16 pixels but you have a container within it with a font size of 12 pixels then 1em = 12px within that container.

Why are they called ems?
It comes from typography as I understand it, em is is pronounced just like it looks and exactly the same as the letter 'm'.  It is used as a measurement of the width for the letter 'M' within the font, this letter is used because it should be the widest in the alphabet, I guess there might be some strange font out there where this isn't the case though.

Why use ems and not just pixels?
The main reason used to be that if the user wanted to increase the text size within their browser they could not do so with pixel defined sizes but could do it with relative defined sizes such as percentages and ems.  This isn't as much of a problem now as modern browsers all zoom the whole page rather than just making the text bigger, one exception to this is Internet Explorer 8 and below which won't zoom text defined in pixel sizes.  There are also all the older versions of browsers from other vendors which pre-date page zooming which won't magnify text defined in pixels, although I believe those ones are dwindling in number quite rapidly (I don't have any facts to back that statement up).

How to use ems properly
Well firstly declare your default pixel size, I'd recommend 16px as it's a good read able size and I'll put a link to an article about it at the end of this post.  Example code below:

html, body{ font-size: 16px; }

Now lets say you wanted to make your heading 1 tags 24 pixels large you take the target size (24) and divide it by the parent size (16) and that will give you the em number you need to use.  I've written this down a bit more mathematically & given an example below:

target size / parent size = em size

24px / 16px = 1.5em

That's all I'm going to say on this subject for now, have a look around on the net for more information if you're interested but I think this is enough to get going with CSS em sizes.

Further reading

Monday, 13 February 2012

What is character encoding?

I thought I'd take a bit of a break from my series on PHP session security and write about character encoding on websites as I've just been reading up on it recently.  I'm not going very in-depth with this subject but have provided links at the bottom to another sites which do. I'll probably write my own detailed post on it one day, it's on my list.

What is character encoding?
It's the method computers use to interpret human languages into a language the computer can understand and store.  For example to store the letter A your computer cannot write it down, it has to store it as a string of 1s and 0s and this has to be the same across all computers otherwise when you send a document from one computer to another the letters would appear different.  There is a bit more to it than that but I'm just trying to keep this quite basic as the specifics shouldn't be to important for understanding what encoding it.

Should I set encoding on my website?
Basically you should set it because if you don't you're reliant on the clients browser working it out correctly (which isn't very easy or 100% accurate) and will depend on their browser, version of the browser and the default languages settings they have set.

What encoding should I use?
This depends a bit on a few things like if your supporting previous applications and which encoding method they used and what languages you need to support but in most situations it's best to use Unicode Transformation Format-8 (UTF-8).  The reason for this is that it is the most common in use today and it interoperates as well as it can with all the other types of encoding out there, well as far as English is concerned anyway unfortunately the interoperability isn't possible for most other languages but it does support any languages you're likely to ever use if it's all in UTF-8.

One quick note as well just to stop any possible confusion with anything else you read UTF-8 it is exactly the same as ISO10646 (RFC 3629).

How do I use the encoding?
This depends on what type of document you're using and how it is being served, I'll be covering what I think are the most common, these are:
  • XHTML served as XML (i.e. properly using XHTML)
  • XHTML served as HTML
  • HTML4 & below
  • HTML5
I'll cover the difference of serving XHTML as XML or as HTML in another post but you'll almost certainly be serving it as HTML, you'd probably already know if you were serving it as XML.

Below is some example code of how to use encoding for your web documents which can be just copy and pasted directly into your documents and it will work, just so you are aware these examples are all for UTF-8.

XHTML served as XML / plain XML
Put this line of code right at the top of your document, even before the doctype declaration.

<?xml version="1.0" encoding="UTF-8"?>

XHTML served as HTML / HTML4 & below
Put this bit of code right at the top of the <head> area in your document.

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

Put this line of code right at the top of the <head> area in your document.  If you were to use the meta tag used in HTML4 in a HTML5 document to declare the correct character set it would still be valid, the new HTML5 method is just similar.

<meta charset="utf-8" />

Further reading

Saturday, 11 February 2012

PHP session security: Part 5 - Session fixation

Edit 14/01/2013
I've updated the "Secure your server against session fixation," section of this post as I felt I'd missed parts out and it wasn't complete enough.

This is another post in my securing PHP session series, this time I'll be covering session fixation.  This is a method used by attackers to set the session id of a legitimate user of your site to what they want it to be so they can impersonate your users.

Brief recap on how PHP sessions work
As explained in a previous post about how PHP session work when a session is made an ID is generated by the server and a file created with the generated id as the name on the server which stores all the session data (such as session variables).  This ID is also set as a cookie value (although there are other methods) with the default name of PHPSESSID (this can be changed) and every time the client makes a request to the server it sends the cookie too.  When the server detects this cookie it checks the session files it has already created and if there is a matching one it'll use the session data from that, if there isn't one it will create a cookie with that ID passed to it and not generate a new ID.

This is all default and most common behaviour for PHP sessions, there are many ways of changing this but this series of articles is concentrating on the default behaviour and how to make it more secure.  I'm also only covering securing PHP session based on using cookies for storage on the client browser because it is the most common and secure method currently in use.

How does session fixation fit into this?
Session fixation is when a hacker some how gains access to some part of the process and manually sets the session ID to one they've generated.  This could be by altering the session ID generation on your server or changing ID stored in the users cookies or a verity of other methods.  How this attack will be performed will depend on your set up and the what they are trying to attack (website, web app etc) and how it works but I'll go into what I consider to be the most common use of PHP session which is a website.  In this scenario it's unlikely your server will have anything altered and far more likely that the cookie on the client is changed or the cookie gets changed while being sent from the client to the server, or vice versa.  This isn't just true for websites but many web applications too.

Now that the hacker has successfully changed the users session ID to one they know, they can set the cookie in their own browser to the one they've changed the clients to and log into your website / web service passing that cookie to your server and in doing so your server will think the hacker is the legitimate user.

This is different to session hijacking (I'll be writing my next post about this) in that session fixation is where the hacker sets the session id to one they'd like but hijacking is when a hacker obtains the session id that's already been set.  The end result is the same, the hacker can impersonate your users but the general thinking / methods behind the attacks are different.

How can this happen?
I can't truly answer this question as I'm no hacker but I can give a very simple example of what can be done, I am sure that there are many other methods of session fixation that I cannot think of, it'd be worth doing a Google search for "How to perform a session fixation attack."

The basic example I can think of is if your server will accept session IDs to be set using any method and not just secure cookies which are set by your server then it's possible that a hacker could send the user to your site via a normal link which also sets the session ID.  When the user clicks the link and is taken to your site, your server will pick up the session ID in the URL and create a session file storing all the session data on the server with the ID set in the link.  This might not be the clearest explanation of what I mean but I can't think of a better way to describe it, I've put an example of the link I've just described below to hopefully make this clearer.

<a href="">Click me!</a>

I hope this helps you understand a little about how these attack take place but do search around for more information as I'm no hacker but I know these vulnerabilities exist.

Secure your server against session fixation
There are probably many methods of securing your server against session fixation and in every application you make it's worth looking into as it'll vary but I suspect for most websites, my upcoming secure PHP login project included, regenerating the session ID should be enough.

Regenerating the session ID is basically exactly what it says, when the user access your site the ID that's passed from their browser to your server is then changed (regenerated) and a new one made which is then sent back to the client browser and stored as a cookie.  This means that even if a hacker changed the session ID cookie on the client browser soon as it's passed to the server it gets changed and the hacker no longer knows what the session ID is.  If there isn't a session ID passed to the server then a new one will have to be generated anyway and as long as the connection is secure it should still prevent session fixation attacks.

I would point out though that this isn't a foul proof method as the client computer could be compromised and as soon as a new cookie is set the attacker gets informed of it but there isn't a huge amount you can do about it because it comes down to the browser manufactures and users themselves to keep their end secure.

There are a couple of methods to try and combat this though, one is the slightly unreliable method which is to hold information about the users machine such as their user-agent and their IP address (others can be included too) and detect changes to them and every time a session ID is used and see if they are the same as previous. If they're not the same then forcing them to re-enter their password should help prevent this, the problem with this of course is that IP address change, are shared between multiple computers and can be spoofed and the browser in use can change which could cause users to have to enter their password in a lot.

Another, probably more useful method is to only allow the user access to parts of the site which don't have any sensitive data on it and making them enter in their password in again every time they try to go to part of the site with more sensitive information in. This in my opinion is the best method in general to be using.

Of course you can always force the user to enter their password every time they enter the website but if you want a 'remember me' kind of link this method wouldn't allow it.

It does depend on how secure you need to make your site / application on what you'd need to do and these are just some options, you'll need to evaluate what will be best for your situation & users each time.

A quite simple method of regenerating the session ID is to use the built in PHP function for this task called session_regenerate_id() which creates a new session ID and keeps all the data from the previous session.  Make sure you set it's parameter to true (it defaults to false) as this will delete the old session file on your server which will stop the old session id from being used again.  I've put an example of the code below:


How often to regenerate the session ID?
This is a bit of a tough question and it does depend on what you're application is using the session data for, but lets say you're using it for a login system (I pick this as I'm currently building one myself).  The consensus seems to be it should regenerated every time the user enters their login details.  They should be entering their login details when they login and every time they try to access more sensitive areas of the site such as a page allowing them to change their password or other personal / sensitive details.

Personally in my secure PHP login project I have been trying to decide between the above or if it should be regenerated on every page load.  I'm not sure but I think regenerating it on every page load would be quite intensive if there were a lot of users (not sure if that's accurate or not) I may add an option in that will allow either method to be used.  I might even have it capable of using both and deciding which to use depending on if a secure connection is in use.  What do you guys think?  Leave a comment with you opinions.

What else can you do?
It's worth doing more research into this as I said before it will depend on your site / application on the best method of securing against this kind of attack, I'm just giving my opinions on the most secure method for what I think are the most common scenarios. Just being aware of this vulnerability while building the site though is a large step towards preventing it as you'll actually start giving it some thought (hopefully).

The only other things I can think of is to make sure your server is set up securely, to only accept session IDs from the client in a secure cookie and to always use a secure connection between the client and server.

Other parts in this series:
Further reading

Thursday, 2 February 2012

PHP session security: Part 4 - Secure connections

Before I start on this subject I wanted to apologise for taking so long about writing this new post, I've been pretty ill recently and have only just started to recover, it was nothing major but I felt bad and couldn't concentrate enough to write this.

This post is the fourth part in my series about PHP session security and will focus on securing the connection between the client and the server.  I've already covered keeping data secure on the server and the session ID secure on the client browser and as important as they are having a secure connection is also a must to stop anyone finding out what the users session ID is and hijacking it.

What is a secure connection
Generally this was done using a Secure Socket Layer (SSL) connection but more recently this has been superseded by Transport Layer Security (TLS) although it is still referred to as SSL in a lot of places.  TLS isn't a totally new method of securing connections but is more of an evolution / upgrade from SSL, still there have been quite a few changes so they cannot interoperate.

Users can normally identify a secure connection as the URL will start with HTTPS (HyperText Transfer Protocol Secured).    I'll write more about HTTPS, SSL & TLS in another post at a later date but understanding how they work shouldn't be important in securing PHP sessions.

Verified & unverified
There are two main types of TLS, verified and unverified (also referred to as certificated & non-certificated depending on the terminology you're using but they're the same thing).  The main difference between these two is that a verified connection will verify the domain with the client browser so it knows the connection is to the correct site, but in an unverified connection this doesn't happen so the client doesn't know it's connected to the correct site but the connection it self is still secure.  You may have noticed on some secured sites that you get a red warning message on your browser warning you that it cannot verify the TLS / SSL certificate (or words to that effect) and asking you if you want to continue or not, these are sites using an unverified TLS / SSL certificate.

Having a verified connection costs more money but when most people see that the connection is unverified with the red warning message there browser shows they will leave the site instantly, so for sites used by the general public you must have a verified certificate.  Unverified SSL is useful for your own purposes where you'll know that you are connected to the correct domain and just want the connection to be secure, an example of this could be an admin system to your website.

How to make a connection secure
There are two main methods of implementing TLS / SSL which are either to have the connection security and cryptography done in hardware or having it all done in software, most (if not everyone) reading this will want to use software as it's the easier and cheaper method.  The advantage of using hardware is that it's more efficient but it has the downside of being harder to upgrade and costing a lot more, it's only of real world use is on sites that have a large volume of traffic such as Facebook so I'll just be going over the software implementation here.

One thing to keep in mind when using a secure connection is that it does use extra resources on the server which is why you've probably not seen many sites which use a secure connection on every page, just the sensitive ones that require it.  It's worth noting though on smaller sites that aren't using much bandwidth or server resources you probably won't notice the extra resources that the secure connection uses even if you were to implement it throughout the whole site.

One of the best places to start is by contacting your hosting provider and seeing if they can sort it out for you as a lot of them have procedures in place for setting up secure connections and getting certificates which makes the whole process a lot easier and quicker for you, possibly cheaper too.

If you want to actually do all the set up yourself you'll need to have a static IP address and full access to your server.  You'll then need to buy the certificate, there are several places to do this and which is best depends on what exactly you're after and the country you're in so ask around, Google is a good place to start and VeriSign are well known for selling certificates.  After you've purchased the SSL certificate you'll need to install / configure your web server (probably Apache) to use it, getting into the details of that is a bit outside the scope of this post and could do with a post all to itself.  I'd recommend Googling around for it and asking on an online forum for advice, for some reason there doesn't seem to be many tutorials on the subject that I could find.  Hopefully later on I'll get around to writing my own guide to configuring an Apache based server to use TLS / SSL.

Other parts in this series:
Further reading

Friday, 20 January 2012

PHP session security: Part 3 - Session ID storage on the client

This is my third post in a series about securing PHP sessions and focuses on how to securely store the session ID stored on the client.  For more information on why you have to store the session ID on the client see my post about how PHP sessions work.

Methods of client side id storage
There are three main methods of storing the session id on the client browser which are, as a cookie, in the URL as a string parameter or in a form as POST data.

Of these three passing it in the URL is the least secure for a number of reasons.  Two main ones are that the session id is visible to anyone who can see that URL.  This doesn't just mean people looking at their screen but also if the user were to copy the URL and send it to someone and anyone who has access to their browsers history.

Passing the session id in POST data is more secure as long as a secure connection is used but can be a bit more awkward as you'll have to make every server request from the client a form submission.  This isn't the most secure method though because as I'm sure you know that when a user makes a page request to the server a page is sent back and this page is stored on the users computer.  This means that the session id that's been set in the page form (generally as a hidden field) is clearly visible in that file, although it does seem unlikely to me that anyone would actually look at this file it is still possible, more so if they are on a public computer.

The most common and secure method is to set a cookie on the clients browser as it can be easily set to only send its value over a secure connection and to the correct domain (there are many other settings too).  What makes this more secure than sending it via POST submissions is that the cookie stored on the client browser should be kept restricted by the browser so not everyone can see and read them other than the user (with the correct tools) and the site that set them.

Using only cookies
I'm going to concentrate mainly on how to secure the session id stored on the client using cookies as this is the most secure and common method using the default PHP session handler.

In PHP version 4.3.0 a setting was introduced, session.use_only_cookieswhich allows you to tell PHP to only use cookies for setting the session id and also only accept session ids sent from the browser in a cookie.  One thing to note however is that up until version 5.3.0 this defaulted to 0, meaning it would set and accept session ids using any method, but since version 5.3.0 defaults to 1 meaning it only sets and accepts session ids from cookies.

There are a few ways of setting this option so cookies are the only method the session id can be sent in, one is to set it directly in the php.ini file but if you don't have access to that you can set it in your PHP script using ini_set() (i.e. ini_set('session.use_only_cookies', 1);).

Securing the cookies
Once your application is set to only set and accept session ids via cookies you'll then need to secure the cookies, which is again not to complicated and just involves changing some settings.

You'll need to make sure the cookie is only available to the correct domain (session.cookie_domain), make sure it's only sent over a secure HTTPS connection (session.cookie_secure) and secure against any hacks that involve getting the cookie values from JavaScript injections, cross-site scripting or various other methods (session.cookie_httponly).  Conveniently there is one setting that will do all of this and a couple more (session.cookie_lifetime) which is session_set_cookie_params (i.e. session_set_cookie_params(0, '/',, true, true);).

Something to note about using cookies is that you are relying on the browser keeping them secure but there have been exploits in browsers before which compromise this (Internet Explorer being the main one but not the only).  As this will almost always be out of your control (possible exception being if you're building an intranet site) you shouldn't ever store any sensitive information such as the usernames, passwords or personal details in a session variable.  I'd recommend encrypting or hashing and information stored in a session variable if it's possible, although I'm aware that in a lot of cases that just wouldn't be practical or even possible.

Hopefully that's been helpful, if so let me know (also if you think I missed anything or just got something plain wrong)!

Other parts in this series:
Further reading

    Thursday, 19 January 2012

    Down temporarily

    I thought I'd just let anyone who reads this know that my blog was down for a short while earlier today because I was setting it up so it uses my own sub-domain rather than the Blogger assigned one.  You may have noticed the URL to this blog is now rather than

    I had been trying to decide if I should do this or just setup a Wordpress blog on the sub-domain then transfer all the posts from here, in the end I decided to stay with Blogger as it's a very good platform (although I do really like Wordpress and use it a lot).  The main thing that convinced me to stay with Blogger was looking around at templates people have made for Blogger and being quite impressed with what you can do.

    Update on the project


    It's been a little while since I wrote anything about this project but I am still working on it but mainly on the documentation side for the moment while everything is fresh in my mind then I'll be back on coding it.  You may have noticed that I'm posting quite a bit here about PHP stuff that's not directly related to this project, that's because I'm intending on linking to these posts from the documentation as an explanation of how some parts of PHP work rather than putting it all in the documentation and making it incredibly long.

    I'll be putting a lot more time into the development of it soon but I'm also reading up lots on HTML5 and CSS3 to make some really cool working examples of what can be done that will be posted on this blog.

    PHP session security: Part 2 - Session storage on your server

    This post continues on from my previous post with an overview of all the PHP session security issues, this one will be the first in the series to start going into more specific detail about each point I made previously.

    Session storage directory
    This is the directory storing the files the session data is saved in, by default this is in the /tmp directory of your server.  The main problem with this comes on a shared server where all session data for all sites hosted on that server are stored in the /tmp directory and everyone using that server has access to it, as mentioned in my previous post the data stored in this file is serialised but is in no way encrypted or secured.

    This isn't quite as bad as it sounds because anyone who looks at this won't be able to figure out which domain on that server each session relates to but they will be able to see all the session ids and data stored within them.  Hopefully you haven't been storing sensitive data in session variables so any information they do find won't be of any use but knowing all those session ids is one of the first steps to hijacking a session, more on that in a separate post.

    This is quite an easy one to fix as there are a few ways of getting around it such as storing all session data in a database, creating your own session handler or easiest of all changing the location of where your session files are stored. I'll be covering the last of these here as this series of posts is about the default PHP session handler but you can Google around and find more information about the other two pretty easily. I'll hopefully get around to writing a post at some point about them myself though.

    To change the location of where sessions are stored you'll need to use the session_save_path() function and make sure that the directory you save to is secured so that people outside the server cannot list or open files in the directory. There are two ways of doing this that I can think of, the first would be to use directory and file permissions (here is a good summary) and the second would be to use .htaccess settings (here is a good article on it).

    I hope this has been helpful, the next post will be about storing the session id on the client.

    Other parts in this series:
    Further reading

    Thursday, 12 January 2012

    PHP session security: Part 1 - Considerations

    I thought I'd make a post about the main security considerations around PHP session security, this will be the first in a few posts about this subject; the others will go more in-depth and give you practical information.

    The first thing to remember is that PHP sessions are not secure by default as many may think.  I've listed all the ones I can think of below and will expand on them in my next post, I'll probably separate some of the points into their own posts too as I'm trying to keep these at a reasonable length.  If you can think of any that I've missed here please leave a comment.
    • Session storage location by default PHP stores its sessions in the /tmp directory of your web server which can be an issue in a shared server because everyones sessions are stored in the same place and you all have access to that directory and its files.
    • Session ID storage on the client can be insecure if passed in the URL rather than in a cookie, POST data can be fairly secure as long as the connection between the client and server is secure (same is true for using cookies) but can often be more awkward to use.
    • Session fixation which is a method of a hacker setting the users session id to something they want so they'll know what the session id is and can impersonate them.
    • Session hijacking is when a hacker finds out what the users session id is and uses it to impersonate them, different to fixation because the hacker in this case is finding out what the session id is rather than setting it themselves.
    • Using a secure connection for all sensitive data sent between the client and server, such as their login credentials and the cookie data.
    • Securing cookie data so it cannot be accessed by anyone else or by any JavaScript used by a hacker on the clients browser.
    • Making the session id non-guessable (if that's even a word), this one is fairly easy as PHP has a pretty random method of generating the ids that would be next to impossible to guess anyway (as far as I'm aware) by default, but you can write your own if you liked.
    • Not storing sensitive data in the session or the cookie held on the client, even if you do everything possible to keep it all secure you're still reliant on the client browser being secure so it doesn't just give the information out to anyone.  Unfortunately this isn't always the case, notably in internet explorer, although as far as I'm aware there isn't currently any security holes in any major up-to-date browsers but I could be wrong but even if I'm right by the time you read this things could have changed.
    Other parts in this series: