Archive for March 11th, 2005

Whole hog CSS layouts

Recently got asked to redo the EBS: European Business Solutions site as it was a bit outdated code wise and we thought it could be a bit friendlier to search engines.
 
The original code was done in an old HTML editor and so contains a lot of font, span, div tags and all the other html that just bloats up a page and can now be replaced by my wonderful friend CSS.
 
In order to make it as search engine friendly as possible i wanted to shift as much of the code into a single CSS file used accross the site.  This means that the ratio of relevant text to code tags on a page is quite high which can help increase your search engine rankings.

 
Its definately worth doing on older sites. For starters, it can save loads of bandwidth!

Stupid free email accounts

So we have a simple login system for our automated reminder system which asks for various details such as name, address, mobile number and lastly, email address.  The email address is quite important as this is a purely online system and so most communication is done through email (such as notifications, billing reminders, special offers, etc).

 
Upon registration an email is sent out confirming the new users email address and password.  Lately I´ve been getting messages rebounded from some of the various free email providers such as Hotmail.  Chances are this is because the user hasn´t checked their account in the last month, as opposed to a false address (since they are along the lines of some_random_string_of_crap74@hotmail.com).
 
I originally didn´t want to use email verification methods as it makes it a more complicated registration process and as it´s a paid for service, I expected users to be responsible with the information they gave.  On second thoughts I´ve decided to implement a verification process where the user is logged in when they click on a link in an email they receive to an address they specify.  This must be done within a certain time which is stored in the database.  This means that anyone not verifying will have their account disabled.

 
The downside to this is that legitimate users would suffer a delay before they can use their account, so I decided to give them a 24 hour grace period, then log them out and disable their account if they haven´t verified by this time. Hopefully it´ll give a more robust system.

Inter-Domain Authentication Methods

One of my latest projects, a trainer & training providers database contains an area for displaying various training venues.  This is to help training providers to find a location to run their training courses in accross the country.
 

We also have another site for advertising training venues which will be used for venues to register and place their adverts.  This will then be added to the database on both sites.  It also logs them in on the Venue Hound site.  The only problem is that I wanted to log them in on Find Trainers as well.
 
What with a large numbers of users having third party cookies disabled, using that as an authentication methos is ruled out.  I could have used the database and login scripts on both sites so they use the same informtaion to login, but that kind of defeats the whole point of trying to have a unified login.
 

I decided to come up with another plan.  Both sites are written in PHP and so any particular page I serve up can have the links modified to different URLs.  Using this and a cookie set for the Venue Hound domain, I can modify the links displayed for Find Trainers to have extra information in the URL.  When the user arrives at findtrainers.co.uk the PHP in the page will take the extra information in the URL, check it with the database and assuming the information is correct, log them in!
 
Hey presto and Bob´s your uncle.  Its not foolproof and you have to be a bit tighter with security, but it works fairly well.