php_penguin

Singletons are a bit of a marmite pattern...people who advocate Unit testing are generally against them, because they promote tight coupling to global resources which makes it hard to test classes in isolation. The need for static methods points to the real problem - resolving dependencies.
 
Singletons DO have a constructor phase where variables can get initialised. Zend_Registry (and many other application level components) use Singleton - and they get a reference via ::getInstance. You could tie the loading of a config file to that method to get the parameters you need. You could just hard code the connection parameters into the class itself. Personally, I think the solution lies elsewhere - using a Singleton causes more problems than it solves.
 
 
If you look at this problem another way, the solution may not be to make the class static, rather to have a mechanism in place to load an instance when you need it...
 
My experience is that Singletons are best used for a specific problem - providing resources globally (and is not always the best method to achieve this*). Rather than creating a Singleton to provide database connections - use a Singleton to pass an instance round your system
 

class Registry{ private static $instance; private function __clone(){} private function __construct(){ } public static function getInstance() { if( !isset( self::$instance ) ) { self::$instance = new self(); } return self::$instance; } public static function get($key){ $instance = self::getInstance(); if(isset($instance->$key)){ return($instance->$key); } } public function set($key,$value){ $instance = self::getInstance(); $instance->$key = value; } }
 
now you can set and get a database connection from the registry instead i.e.
 
 

Registry::set('dbConn',new DB_Connection($config_file)) Registry::get('dbConn');
 
Memory issues are another concern you expressed. To be honest - loading a database connection class is pretty negligible.
 
http://phparch.com/2010/03/03/static-methods-vs-singletons-choose-neither/
 
You can, however, deal with this using a pattern called Lazy Load.
http://www.devshed.com/c/a/PHP/Lazy-and-Eager-Loading-in-PHP-5/
 
*I recommend taking a look at dependency injection, but this is a whole other kettle of fish...
http://fabien.potencier.org/article/11/what-is-dependency-injection
 
I also recommend taking a look at this great site:
http://sourcemaking.com/design_patterns

(I'll build this tutorial up over time)
 
I've recommended it a few times before now and felt this deserved it's own topic rather than a reply to ayoungh's topic (amongst others).
 
I've been using CI for about 2 years now, and have made plenty of commercial systems using it, as well as loads of personal projects.
 
For this tutorial, I'll go through how I made the first half of my most recent personal project (nvoice.co.uk). I might avoid certain topics or glaze over them, so if you're confused just let me know.
 
My MSN/Skype is listed in my profile so if you have questions, ask me there or on here.
 
Part 1: Installation & configuration
 
Installation
First thing you want to do is download CI from the website (http://www.codeigniter.com), currently at version 1.73, and unzip it into a folder in your webroot. That's it - CI is now installed!
 
For this tutorial, the folder is /var/www/nvoice/ (or C:/Apache2/httproot/nvoice/)
 
From now on, this folder will be shown to as "~", eg "~/system/application/controllers".
 
Configuration
There are *tons* of config options for CI, but most are thankfully optional. A few, however, are very much not, and you need to set them correctly before you start work.
 
All config files live in ~/system/application/config, and are well-named. Here's a run down of the important config files:


autoload.php - Defines which files are automatically loaded, and is very useful. You *will* be auto-loading libraries, models and helpers.
config.php - The most important file - defines your BASE_URL, INDEX_PAGE, and a few other bits and pieces.
database.php - Your database connection info.
hooks.php - If you are using hooks, you'll be using this file.
routes.php - Routes are very handy, and they are defined in here. To set up a system, you need to define your config:BASE_URL and database settings at the minimum. You will also probably add some helpers to your autoload list, enable config:GLOBAL_XSS_FILTERING and change your routes file. (more on routes later)
 
So, set your base url to "http://localhost/nvoice/", your database settings appropriately, and add the following autoload settings:
Libraries: database, session
Helpers: url, html, cookie
Part 2: System components - what are models, controllers, views, libraries, and helpers?
 
This is by far the most commonly misunderstood component of CI at first, and probably also the most asked question on the forums. Here's a very quick explanation of each type... but frankly, clarification best comes from creating stuff with the system and no words I can write will give you ultimate truth in this matter.

Models: Classes designed to interact with a database table (or database view) directly, providing useful functions to be used by controllers or other models. Generally these follow a CRUD pattern.
Controllers: The beating heart of your system - these get loaded based on the (routed) URL and basically control what your system will do on each page. Generally, each function should be no more than 10 lines long and contain almost no logic. Any more than that and you need to rethink what you are doing.
 
Views: These are where ALL your HTML goes, split into relative templates and parts of templates, for example a separate view for header and footer. Generally, these should contain no logic beyond simple loops and if statements.
 
Libraries: These are classes similar to a Model, but typically work on things other than the database, or as an amalgamation/extension of two or more Models. An example would be a templating library, or a library for handling image editing or manipulation.
 
Helpers: Groups of functions related to each other, but which do not require a shared memory space (in which case you'd use a library).
--tbf--

Alternative title: "advice I wish I had been given at the start of this job, based on my experience as a web developer but probably applies to other professions (except I didn't want to be so obnoxious as to expect they all did)"
 
What follows is a list of rules of thumb that I find myself following (and not following where required), general bits of knowledge, etc. Please reply with rules of your own!
 

It doesn't matter what you use (within reason) - so long as you use it well
Time and again I see topics on forums asking "what text editor/IDE/OS/browser should I use?" - and often the answer is different every single time. This is because the recommendations are based on what works for the person answering, and that is founded on only one thing: experience!
Wether you choose between an IDE (Netbeans?) or plain text editor (notepad) or somewhere in between (notepad++, gedit) the only thing that you *must* do is fully understand the program, it's keyboard shortcuts and additional tools (snippets, code checking, class browser, code folding etc). When you truly know a program you will be able to rattle at your keyboard and lay your thoughts down as they occur, without *thinking* about how to move between pieces of code. That said, here's my choices (and why)
Ubuntu 10.10 - free OS software that I can customise as much as I want, and have it such that I can do *all* window management tasks from the keyboard. gEdit text editor - default in Ubuntu, has the features I need but nothing more. Starts up instantly, snippets, external tools, syntax highlighting, compile-on-key. Firefox + Firebug - for any Javascript development, Firebug is verging on essential, simple as! Bash (gnome-terminal), GIMP, Docky (timer plugin!) [*]Know a little bit of everything. Know everything of a few things
It is very rare that you will get a job requiring only one piece of knowledge (only jQuery, for example) and even worse, you'll be limiting your potential by seeking jobs like this. That's why it's best to know a small amount about all things, a good amount about things related to your chosen tool (HTML for jQuery + PHP, for example), and absolutely everything about one thing.
The thing is, the knowledge in each of these areas complement each other and enhance your abilities in the primary choice... and your knowledge will increase in the secondary areas much quicker than expected.[*]In the words of Marcellus Wallace: "F*** Pride"
Don't bother getting into this professionally if you will put your pride above all else. Sometimes you *will* have to take jobs that you find boring, annoying, or even a bit morally ambiguous. You can always turn these down... but sometimes these jobs lead to better jobs, or sometimes you just need to pay the rent.[*]How to estimate
First thing to say when someone asks you to estimate? "I'll get back to you", or words to that effect. Unless the job will obviously only take an hour or two, give this answer. Anything else is dishonest.
Now, to estimate a task you must make sure you have adequate data to provide an estimate. Don't be afraid to ask for more info - the clients will invariably prefer that you ask too much than not enough.
To estimate, break down the task into smaller tasks. Repeat this recursively until no individual task takes more than half a day. Add up the number of tasks and multiply it by 1/2 for a minimum, and 1 for a maximum number of days. If we have 35 tasks to completion, it will take 18 to 35 days. Apply your own judgment!
Now we have a number of days, we turn it into an appropriate figure.
If it's less than 15 days, say it in days
If it's less than 8 weeks, say it in weeks (there are 5 days in a week, not 7... 35 days = 7 weeks)
If it's less than 30 weeks, say it in months
If it's longer than that, the task is probably too large - try break into multiple deliverables.[*]Always get something signed (or use escrow)
Until you can trust the person you are working with (repeat work, or a family friend) you must assume they are out to bite you in the ass. Always get a signature on a contract, or a confirmed amount in an escrow service. ALWAYS.[*]Backup, Backup, Backup
Ideally this will be a regular SVN/GIT commit to a remote server, but if you can't do that, at least do an auto-tar+upload (rsync) to somewhere safe (external HDD and/or remote server).[*]Use a CLI (bash or cygwin)
A Command-Line-Interface is an incredibly powerful tool for file search and manipulation, and you really should get over the initial fear caused by the complete lack of mouse-based interaction. For linux users just run a terminal and you're done (bind to ctrl+alt+t), for Windows users see Cygwin for (almost) identical features. Learn how to pipe between commands, how to use find, awk, sed, grep, and anything else you come across. Read the man page for everything (man command = user-guide for command)[*]Document everything
Just because you're the only one working on a section of code or even a whole project, write comments on all your code. Whilst it does benefit other programmers, it's primary beneficiary is *you*. Writing comments before you write the code helps clarify what the code is meant to do, and writing it down in easy form means you can more easily see any logical inconsistencies.[*]Use a commenting microlanguage
You can use a specific comment format which allows you to auto-generate documentation for all your classes and their methods. Javadoc, PHPDoc, and JSDoc all follow the same format, and there is a similar implementation for most languages.[*]What to comment?
A difficult question to answer really, as it's best taught through experience.. for simple commands just comment what that "section" of commands will do - for complex stuff, or stuff that vastly changes the form of the data put a comment per line. Anything that strings multiple functions together should be commented. See sunwukung's comment

more to follow

Alternative title: "advice I wish I had been given at the start of this job, based on my experience as a web developer but probably applies to other professions (except I didn't want to be so obnoxious as to expect they all did)"
 
What follows is a list of rules of thumb that I find myself following (and not following where required), general bits of knowledge, etc. Please reply with rules of your own!
 

It doesn't matter what you use (within reason) - so long as you use it well
Time and again I see topics on forums asking "what text editor/IDE/OS/browser should I use?" - and often the answer is different every single time. This is because the recommendations are based on what works for the person answering, and that is founded on only one thing: experience!
Wether you choose between an IDE (Netbeans?) or plain text editor (notepad) or somewhere in between (notepad++, gedit) the only thing that you *must* do is fully understand the program, it's keyboard shortcuts and additional tools (snippets, code checking, class browser, code folding etc). When you truly know a program you will be able to rattle at your keyboard and lay your thoughts down as they occur, without *thinking* about how to move between pieces of code. That said, here's my choices (and why)
Ubuntu 10.10 - free OS software that I can customise as much as I want, and have it such that I can do *all* window management tasks from the keyboard. gEdit text editor - default in Ubuntu, has the features I need but nothing more. Starts up instantly, snippets, external tools, syntax highlighting, compile-on-key. Firefox + Firebug - for any Javascript development, Firebug is verging on essential, simple as! Bash (gnome-terminal), GIMP, Docky (timer plugin!) [*]Know a little bit of everything. Know everything of a few things
It is very rare that you will get a job requiring only one piece of knowledge (only jQuery, for example) and even worse, you'll be limiting your potential by seeking jobs like this. That's why it's best to know a small amount about all things, a good amount about things related to your chosen tool (HTML for jQuery + PHP, for example), and absolutely everything about one thing.
The thing is, the knowledge in each of these areas complement each other and enhance your abilities in the primary choice... and your knowledge will increase in the secondary areas much quicker than expected.[*]In the words of Marcellus Wallace: "F*** Pride"
Don't bother getting into this professionally if you will put your pride above all else. Sometimes you *will* have to take jobs that you find boring, annoying, or even a bit morally ambiguous. You can always turn these down... but sometimes these jobs lead to better jobs, or sometimes you just need to pay the rent.[*]How to estimate
First thing to say when someone asks you to estimate? "I'll get back to you", or words to that effect. Unless the job will obviously only take an hour or two, give this answer. Anything else is dishonest.
Now, to estimate a task you must make sure you have adequate data to provide an estimate. Don't be afraid to ask for more info - the clients will invariably prefer that you ask too much than not enough.
To estimate, break down the task into smaller tasks. Repeat this recursively until no individual task takes more than half a day. Add up the number of tasks and multiply it by 1/2 for a minimum, and 1 for a maximum number of days. If we have 35 tasks to completion, it will take 18 to 35 days. Apply your own judgment!
Now we have a number of days, we turn it into an appropriate figure.
If it's less than 15 days, say it in days
If it's less than 8 weeks, say it in weeks (there are 5 days in a week, not 7... 35 days = 7 weeks)
If it's less than 30 weeks, say it in months
If it's longer than that, the task is probably too large - try break into multiple deliverables.[*]Always get something signed (or use escrow)
Until you can trust the person you are working with (repeat work, or a family friend) you must assume they are out to bite you in the ass. Always get a signature on a contract, or a confirmed amount in an escrow service. ALWAYS.[*]Backup, Backup, Backup
Ideally this will be a regular SVN/GIT commit to a remote server, but if you can't do that, at least do an auto-tar+upload (rsync) to somewhere safe (external HDD and/or remote server).[*]Use a CLI (bash or cygwin)
A Command-Line-Interface is an incredibly powerful tool for file search and manipulation, and you really should get over the initial fear caused by the complete lack of mouse-based interaction. For linux users just run a terminal and you're done (bind to ctrl+alt+t), for Windows users see Cygwin for (almost) identical features. Learn how to pipe between commands, how to use find, awk, sed, grep, and anything else you come across. Read the man page for everything (man command = user-guide for command)[*]Document everything
Just because you're the only one working on a section of code or even a whole project, write comments on all your code. Whilst it does benefit other programmers, it's primary beneficiary is *you*. Writing comments before you write the code helps clarify what the code is meant to do, and writing it down in easy form means you can more easily see any logical inconsistencies.[*]Use a commenting microlanguage
You can use a specific comment format which allows you to auto-generate documentation for all your classes and their methods. Javadoc, PHPDoc, and JSDoc all follow the same format, and there is a similar implementation for most languages.[*]What to comment?
A difficult question to answer really, as it's best taught through experience.. for simple commands just comment what that "section" of commands will do - for complex stuff, or stuff that vastly changes the form of the data put a comment per line. Anything that strings multiple functions together should be commented. See sunwukung's comment

more to follow

Alternative title: "advice I wish I had been given at the start of this job, based on my experience as a web developer but probably applies to other professions (except I didn't want to be so obnoxious as to expect they all did)"
 
What follows is a list of rules of thumb that I find myself following (and not following where required), general bits of knowledge, etc. Please reply with rules of your own!
 

It doesn't matter what you use (within reason) - so long as you use it well
Time and again I see topics on forums asking "what text editor/IDE/OS/browser should I use?" - and often the answer is different every single time. This is because the recommendations are based on what works for the person answering, and that is founded on only one thing: experience!
Wether you choose between an IDE (Netbeans?) or plain text editor (notepad) or somewhere in between (notepad++, gedit) the only thing that you *must* do is fully understand the program, it's keyboard shortcuts and additional tools (snippets, code checking, class browser, code folding etc). When you truly know a program you will be able to rattle at your keyboard and lay your thoughts down as they occur, without *thinking* about how to move between pieces of code. That said, here's my choices (and why)
Ubuntu 10.10 - free OS software that I can customise as much as I want, and have it such that I can do *all* window management tasks from the keyboard. gEdit text editor - default in Ubuntu, has the features I need but nothing more. Starts up instantly, snippets, external tools, syntax highlighting, compile-on-key. Firefox + Firebug - for any Javascript development, Firebug is verging on essential, simple as! Bash (gnome-terminal), GIMP, Docky (timer plugin!) [*]Know a little bit of everything. Know everything of a few things
It is very rare that you will get a job requiring only one piece of knowledge (only jQuery, for example) and even worse, you'll be limiting your potential by seeking jobs like this. That's why it's best to know a small amount about all things, a good amount about things related to your chosen tool (HTML for jQuery + PHP, for example), and absolutely everything about one thing.
The thing is, the knowledge in each of these areas complement each other and enhance your abilities in the primary choice... and your knowledge will increase in the secondary areas much quicker than expected.[*]In the words of Marcellus Wallace: "F*** Pride"
Don't bother getting into this professionally if you will put your pride above all else. Sometimes you *will* have to take jobs that you find boring, annoying, or even a bit morally ambiguous. You can always turn these down... but sometimes these jobs lead to better jobs, or sometimes you just need to pay the rent.[*]How to estimate
First thing to say when someone asks you to estimate? "I'll get back to you", or words to that effect. Unless the job will obviously only take an hour or two, give this answer. Anything else is dishonest.
Now, to estimate a task you must make sure you have adequate data to provide an estimate. Don't be afraid to ask for more info - the clients will invariably prefer that you ask too much than not enough.
To estimate, break down the task into smaller tasks. Repeat this recursively until no individual task takes more than half a day. Add up the number of tasks and multiply it by 1/2 for a minimum, and 1 for a maximum number of days. If we have 35 tasks to completion, it will take 18 to 35 days. Apply your own judgment!
Now we have a number of days, we turn it into an appropriate figure.
If it's less than 15 days, say it in days
If it's less than 8 weeks, say it in weeks (there are 5 days in a week, not 7... 35 days = 7 weeks)
If it's less than 30 weeks, say it in months
If it's longer than that, the task is probably too large - try break into multiple deliverables.[*]Always get something signed (or use escrow)
Until you can trust the person you are working with (repeat work, or a family friend) you must assume they are out to bite you in the ass. Always get a signature on a contract, or a confirmed amount in an escrow service. ALWAYS.[*]Backup, Backup, Backup
Ideally this will be a regular SVN/GIT commit to a remote server, but if you can't do that, at least do an auto-tar+upload (rsync) to somewhere safe (external HDD and/or remote server).[*]Use a CLI (bash or cygwin)
A Command-Line-Interface is an incredibly powerful tool for file search and manipulation, and you really should get over the initial fear caused by the complete lack of mouse-based interaction. For linux users just run a terminal and you're done (bind to ctrl+alt+t), for Windows users see Cygwin for (almost) identical features. Learn how to pipe between commands, how to use find, awk, sed, grep, and anything else you come across. Read the man page for everything (man command = user-guide for command)[*]Document everything
Just because you're the only one working on a section of code or even a whole project, write comments on all your code. Whilst it does benefit other programmers, it's primary beneficiary is *you*. Writing comments before you write the code helps clarify what the code is meant to do, and writing it down in easy form means you can more easily see any logical inconsistencies.[*]Use a commenting microlanguage
You can use a specific comment format which allows you to auto-generate documentation for all your classes and their methods. Javadoc, PHPDoc, and JSDoc all follow the same format, and there is a similar implementation for most languages.[*]What to comment?
A difficult question to answer really, as it's best taught through experience.. for simple commands just comment what that "section" of commands will do - for complex stuff, or stuff that vastly changes the form of the data put a comment per line. Anything that strings multiple functions together should be commented. See sunwukung's comment

more to follow

Alternative title: "advice I wish I had been given at the start of this job, based on my experience as a web developer but probably applies to other professions (except I didn't want to be so obnoxious as to expect they all did)"
 
What follows is a list of rules of thumb that I find myself following (and not following where required), general bits of knowledge, etc. Please reply with rules of your own!
 

It doesn't matter what you use (within reason) - so long as you use it well
Time and again I see topics on forums asking "what text editor/IDE/OS/browser should I use?" - and often the answer is different every single time. This is because the recommendations are based on what works for the person answering, and that is founded on only one thing: experience!
Wether you choose between an IDE (Netbeans?) or plain text editor (notepad) or somewhere in between (notepad++, gedit) the only thing that you *must* do is fully understand the program, it's keyboard shortcuts and additional tools (snippets, code checking, class browser, code folding etc). When you truly know a program you will be able to rattle at your keyboard and lay your thoughts down as they occur, without *thinking* about how to move between pieces of code. That said, here's my choices (and why)
Ubuntu 10.10 - free OS software that I can customise as much as I want, and have it such that I can do *all* window management tasks from the keyboard. gEdit text editor - default in Ubuntu, has the features I need but nothing more. Starts up instantly, snippets, external tools, syntax highlighting, compile-on-key. Firefox + Firebug - for any Javascript development, Firebug is verging on essential, simple as! Bash (gnome-terminal), GIMP, Docky (timer plugin!) [*]Know a little bit of everything. Know everything of a few things
It is very rare that you will get a job requiring only one piece of knowledge (only jQuery, for example) and even worse, you'll be limiting your potential by seeking jobs like this. That's why it's best to know a small amount about all things, a good amount about things related to your chosen tool (HTML for jQuery + PHP, for example), and absolutely everything about one thing.
The thing is, the knowledge in each of these areas complement each other and enhance your abilities in the primary choice... and your knowledge will increase in the secondary areas much quicker than expected.[*]In the words of Marcellus Wallace: "F*** Pride"
Don't bother getting into this professionally if you will put your pride above all else. Sometimes you *will* have to take jobs that you find boring, annoying, or even a bit morally ambiguous. You can always turn these down... but sometimes these jobs lead to better jobs, or sometimes you just need to pay the rent.[*]How to estimate
First thing to say when someone asks you to estimate? "I'll get back to you", or words to that effect. Unless the job will obviously only take an hour or two, give this answer. Anything else is dishonest.
Now, to estimate a task you must make sure you have adequate data to provide an estimate. Don't be afraid to ask for more info - the clients will invariably prefer that you ask too much than not enough.
To estimate, break down the task into smaller tasks. Repeat this recursively until no individual task takes more than half a day. Add up the number of tasks and multiply it by 1/2 for a minimum, and 1 for a maximum number of days. If we have 35 tasks to completion, it will take 18 to 35 days. Apply your own judgment!
Now we have a number of days, we turn it into an appropriate figure.
If it's less than 15 days, say it in days
If it's less than 8 weeks, say it in weeks (there are 5 days in a week, not 7... 35 days = 7 weeks)
If it's less than 30 weeks, say it in months
If it's longer than that, the task is probably too large - try break into multiple deliverables.[*]Always get something signed (or use escrow)
Until you can trust the person you are working with (repeat work, or a family friend) you must assume they are out to bite you in the ass. Always get a signature on a contract, or a confirmed amount in an escrow service. ALWAYS.[*]Backup, Backup, Backup
Ideally this will be a regular SVN/GIT commit to a remote server, but if you can't do that, at least do an auto-tar+upload (rsync) to somewhere safe (external HDD and/or remote server).[*]Use a CLI (bash or cygwin)
A Command-Line-Interface is an incredibly powerful tool for file search and manipulation, and you really should get over the initial fear caused by the complete lack of mouse-based interaction. For linux users just run a terminal and you're done (bind to ctrl+alt+t), for Windows users see Cygwin for (almost) identical features. Learn how to pipe between commands, how to use find, awk, sed, grep, and anything else you come across. Read the man page for everything (man command = user-guide for command)[*]Document everything
Just because you're the only one working on a section of code or even a whole project, write comments on all your code. Whilst it does benefit other programmers, it's primary beneficiary is *you*. Writing comments before you write the code helps clarify what the code is meant to do, and writing it down in easy form means you can more easily see any logical inconsistencies.[*]Use a commenting microlanguage
You can use a specific comment format which allows you to auto-generate documentation for all your classes and their methods. Javadoc, PHPDoc, and JSDoc all follow the same format, and there is a similar implementation for most languages.[*]What to comment?
A difficult question to answer really, as it's best taught through experience.. for simple commands just comment what that "section" of commands will do - for complex stuff, or stuff that vastly changes the form of the data put a comment per line. Anything that strings multiple functions together should be commented. See sunwukung's comment

more to follow

I posted this on my Facebook for my CompSci friends to see, figured it'd be helpful outside of those 50 or so people.
 
"Sidejacking" is when a hacker uses a packet-sniffer to detect the login auth cookie and uses that cookie data himself to pretend to be authorised on a website.
 
This is possible because mostly what we do to say that a user is authorised is create a unique hash (using sha1 or similar) and store it in both the database and the cookie:

salt = sha1( username + password + time() ) cookie['login'] = salt database.write( login = salt )
 
Then to check that the user is authorised, we do

if( database.get_where( login = cookie['login'] ) ) ...
 
Sidejacking works because the cookie can be used from any location. How to stop this? Add some user-specific data (IP and user agent) based encryption and store two different hashes like so:

salt = sha1( username + password + time() ) cookie['login'] = salt database.write( login = sha1( salt + IP + UA ) )

if( database.get_where( login = sha1( cookie['login'] + IP + UA ) ) ...
 
Now a sidejacking attempt can't work because the IP and UA is required to transmute from the cookie salt to the DB salt. Simples
 
Note that this won't stop all attacks - the UA is not unique to each user and sidejacking often occurs within the same network (so the IP is shared beyond the router), but it will stop most of the rudimentary attempts when you can't get SSL running throughout the site.
 
(The easiest and most complete method of stopping sidejacking is using SSL (https) encryption for all authorised pages so that cookies/sessions can't be grabbed by a packet sniffer. However, that's not always a possibility due to server or cost restraints.)

I posted this on my Facebook for my CompSci friends to see, figured it'd be helpful outside of those 50 or so people.
 
"Sidejacking" is when a hacker uses a packet-sniffer to detect the login auth cookie and uses that cookie data himself to pretend to be authorised on a website.
 
This is possible because mostly what we do to say that a user is authorised is create a unique hash (using sha1 or similar) and store it in both the database and the cookie:

salt = sha1( username + password + time() ) cookie['login'] = salt database.write( login = salt )
 
Then to check that the user is authorised, we do

if( database.get_where( login = cookie['login'] ) ) ...
 
Sidejacking works because the cookie can be used from any location. How to stop this? Add some user-specific data (IP and user agent) based encryption and store two different hashes like so:

salt = sha1( username + password + time() ) cookie['login'] = salt database.write( login = sha1( salt + IP + UA ) )

if( database.get_where( login = sha1( cookie['login'] + IP + UA ) ) ...
 
Now a sidejacking attempt can't work because the IP and UA is required to transmute from the cookie salt to the DB salt. Simples
 
Note that this won't stop all attacks - the UA is not unique to each user and sidejacking often occurs within the same network (so the IP is shared beyond the router), but it will stop most of the rudimentary attempts when you can't get SSL running throughout the site.
 
(The easiest and most complete method of stopping sidejacking is using SSL (https) encryption for all authorised pages so that cookies/sessions can't be grabbed by a packet sniffer. However, that's not always a possibility due to server or cost restraints.)