tags:

views:

217

answers:

9

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)?

A: 

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.

Lizard
A: 
  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.

Kyle J. Dye
A: 

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.

Paulo
A: 

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.

Damien MATHIEU
+1  A: 

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.

ryeguy
+2  A: 

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).

DisgruntledGoat
A: 
  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.
Citizen
A: 

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.

Abdel Olakara
A: 

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

meade