Well, I'm not sure if I can help. You have a lot going on and most of the code looks okay but I don't understand why you are asking about sessions but not using them...
I see in users.php that you start your session as normal but then change the session id to "test". This would give everyone that accesses users.php the same session id! But, keep in mind that this isn't the actual session_id, it is a variable associated with that session named "id".
The session id should be something unique every time. Simply by starting a session, the server automatically creates a new one so it isn't necessary to set the id yourself. Then in the files shown here, you never use any session information. Instead, you rely on ip addresses as the key to your database which could have some real problems with it. For example, if you have a user log in many times from the same IP address, the database may have hundreds or even thousands of records using that IP. This could cause cause errors down the road if you aren't careful with how you check fro existing sessions. This is why most developers use the server generated session id as the database key.
Your timestamp issue I think is where you have the trouble.
First, the next two code bits do exactly the same thing:
CODE
$w=date('W');
$d=date('d');
$m=date('m');
$y=date('Y');
$h=date('H');
$tim1=$w.$y.$m.$d.$h;
echo tim1 . "<br />\n";
CODE
$tim2=date('WYmdH');
echo tim1 . "<br />\n";
which as of right now would give you this: 442007110100
The 44th week in 2007 on the 11th month and 1st day at 0 hours past midnight.
Not exactly a highly usable variable to use. And an MD5 hash of this looks like this: 30687663fc34e16d5c272ddf2f44fbc5 which is what $timd is set to.
Now for your variable $session after 2 hours would be explained as such:
CODE
$session=442007110100-442007110102;
Which is -2.
However, if you do change the $session variable to this:
CODE
$session=$tim-$time;
it would b 2.
But even at that, once a new year starts, you'll have problems since the first part of your time value is the week of the year so January 1, 2008 would look like this:
12008010100
and then session could be set like this even if you switched $time and $tim:
CODE
$session=12008010100-442007110100;
Which is -429999100000.
If you don't switch $time and $tim:
CODE
$session=442007110100-12008010100;
Which is 429999100000.
See how this could be a serious problem... If I log into your site today and then somebody that has the same IP address goes to your site in January without me returning in between they will be logged in as me! This could happen with users of dial up internet access or dynamically assigned IP address broadband access. Which is still quite common. Just between December 31, 2007 and January 1, 2008 there would be issues and that could be less that an hour old session...
I think you would be better server using a Unix timestamp which will always get larger every second...
time() will return the current Unix timestamp which right now is 1193902752 and now is 1193902765 and now is 1193902771.
It increases by 1 every second and is a calculation of the number of seconds since January 1 1970 00:00:00 GMT.
This is easily formated into any date formate you want with the date function and is the figure used by default when you use date without the timestamp argument.
Since this number is extremely predictable, most developers use it.
Now for the next problem...
When you have a session greater than "5", you update the MD5 of the time value but you don't update the actual time value! Since your comparison is based on the time value $tim and not $timd, you would be better off to update session.time in the database instead of session.time_stamp. Since currently your session time in the database never gets updated, the comparison will not work correctly.
I don't understand the need for $timd. the MD5 hash of $tim doesn't seem to be necessary. You could just as easily drop that from your script and check to see if there is a value for session.time instead. Which if you use my suggestion to use a Unix timestamp instead of what you now use, you could check for a valid session with the database query. For example:
CODE
$current_time = time();
$maximum_session_life = 3600; // 3600 seconds equals 1 hour
$session_cut_off = $current_time - $maximum_session_life; // Basically, the session had to have been created less than 3601 seconds ago.
$ip=$_SERVER['REMOTE_ADDR'];
$query = "SELECT id, session_details, timestamp FROM session WHERE id = '$ip' AND timestamp >= '$session_cut_off'";
// Additional query code here followed by whatever you want to do if data is returned...
Now this would only return a result if the id was in the database already AND the session time in the database was not too old...
I would imagine that if it were too old, you would simply want to redirect the user to the login page. Otherwise, you have to UPDATE the timestamp in the database like so:
CODE
if(count($row) > 0 && $row['session_details'] != ''){
$session_details = $row['session_details'];
$timestamp = $row[2];
mysql_query("UPDATE session SET timestamp = '" . time() . "' where id = '$ip' ");
}
else{
header ("location: /login.php");
}
So that check to see if a result was returned and if the the field session_details has a value applied to it. If it does, update the timestamp otherwise redirect to the login page.
Now as I suggested at the beginning, I think you should use session_id() instead of $_SERVER['REMOTE_ADDR'] for your table key. This will reduce dynamic IP issues and is easier to deal with since it is generally a good idea to generate a new session id if the previous one is expired. You don't need to use $_SESSION for anything unless you prefer to use that instead of the database to store information about the user. For example, you could assign some details about the user like his name in the $_SESSION variable and use that instead of querying the database each time you want to say "Hello John Doe!".
Of course, if you do actually use the PHP session functions, you really should generate a new session id when a session expires and the user has to log in again.
I have given you a lot of information here. Between this and my previous reply, I'm sure you'll have many questions.
good luck,
vujsa
Comment/Reply (w/o sign-up)