Web Session or Sessionless

I'm thinking about creating a 'session' table that contains a random #, User ID, Date/Time that is populated when a user logs in and the random # used in each displayed page to uniquely identify the person. Each time the user displays a page the record will be updated with the most recent date/time activity, if there has been no activity in the past x hours than I plan on forcing a re-signon. Couple of questions:

• should I include IP (I'm not the concerned about multi-sessions, but thought of it for added security)
• does this work better and is it more secure than the standard PHP session approach (cookies, etc.)
• should I use this method as well as php session (cookie) to match the two to make sure its the right person (cookie including IP, etc.??)

Is there a better approach or standard security pattern that is out开发者_开发技巧 there (and I don't know about)?

Your method sounds strikingly similar to cookies to me. You set a value somewhere then check it on each page load. I don't see a need to reinvent the wheel when cookies/sessions are perfectly adequate.

In general I prefer to use cookies because then users can stay logged in between sessions (i.e. when they close their browser and come back).

Why not just using the default PHP session and storing it's datas in a database ?
There are several functions allowing you to redefine what PHP does when the session is accessed or updated.

This article explains that.

Do not use IPs. Although that will work for most people, some may have dynamic IPs. A visitor could be behind his ISP's load balanced proxy farm, for example.

Point 1 - Depends if people are on static IP's

Point 2 - Storing sessions in database would be required for load balancing and redundancy issues. It also depends upon how busy your application will be.

Point 3 - One or the other should be adequate.

1. The IP can be helpful, but in the case of someone having a dynamic IP, it is not recommended for anything more than a reference point.

2. I would suggest using a session approach because it is typically a 20-minute timeout unless changed by the server admin.

I'd suggest only choosing one method and ensuring it works properly. Having multiple verifications sounds nice but it usually just adds complexity and bugs without adding any extra features.

Store the values in sessions since it's less overhead and you can set the session to expire when you like. This solves the entire "last time they logged in thing" without excess calculations.

The entire purpose of a session is to store values related to that person on that computer which is exactly what you are looking for. Duplicating that seems redundant.

1. Use cookies to populate the session.
2. Use the session for your normal usage.
3. Be sure to have a random string stored via db per session.
4. Save the IPs to db just for your own info incase you need to do a temp IP ban, but dont use them like they're infallible.

Why do you need to use database for track sessions. Don't you think its a overhead? I would suggest you go ahead with PHP sessions.

I'm using CodeIgniter - they have a built in session handler which seems to use both cookies and the database (one checking the other) - everything I was looking for....frameworks work

The answer Both!

The main point: You should never blindly accept cookies or sessions to validate users, both of which are easily stolen by XSS, and can be used by a malicious user other than the origin.

For user validation, since you're making a trip to validate the user anyway, there isn't really an overhead. You are simply applying a value to when they logged in to the database, and validating it via some means on each page load.

A method I chose was a checkin-checkout method of the user's session state. In which a unique ID is created on page load and a session variable stores this unique ID. This unique ID is also stored for the User ID in the database, along with IP Address and IP changes. (I also stored other bits of info that are validated)

This can be used to prevent 2 separate browsers from being logged in at the same time for a single User ID, which can't be done with just sessions since sessions don't care who created them or when. But with checkin-checkout, since the Unique ID is always different, a mismatch would occur.

The script validates the Unique ID from the session value and IP Address in the database. Once a match is made, change the Unique ID and update the database. If the IP was changed within x seconds, do something for that user (Force new login), if the Unique ID's don't match do something else (such as logout, warn, etc), if last activity was x seconds ago do something for that user.

So Login->Create Session/User Validation->Next Page->Validate Session with Database Unique ID + Validate User->Generate New Session Unique ID->Update User Last On/Unique ID

In the end it can give you a better overview of where your users are accessing their accounts from and how often from each point EG: work x 3, home x 5, mobile x 1. And can also allow you to protect your users from account thefts. EG: A German user suddenly logs in from Thailand, or The US. Notify them of the change and send a request to verify the change to their email.