Couch Sessions

Thakns for this very descriptive and encouraging article. What I feel as lacking in all the documents and articles appearing here and there most written by volunteers is how the session data files created in the file system of the server (in php4) are destroye if explicit session_destroy().

Another point I wonder is that if some person gets a valid session id can he/she abuse this and act as if he/she is who is the real owner of the session id.


Since session id are most of the time given in close relation with authentication, a session id may, in many sites, mean that the client is authenticated. So, does having a valid session id (even guessing one, whizh is active by achance at the time of guessing) mean that the bad guy will have all the rights and privilidge that the real owner of the session id has.

I may be wrong in using the php4 and sessions jargon as I am a newbie.

I would appreciate if some genious friends enlightens us by touching these aspects of this SESSION wonder of PHP4

Great thanks to all who contribute to prolifiration of open source s/w

bye

Hello

is there a difference between a "session cookie" and a "normal" cookie? My concern is the following, if the client doesen't accept cookies my session cookie will be rejected!!

Thanks for your help

Marcel

The easiest way to stop people guessing sessions is to do a basic IP check against the session. Store the IP of the user who you created the session id and compare it against that of the person using the id. If there's no match force the user to log in again.
<br>
<br>
There may be a more elegant way to do it but this works and is fairly simple to do.

IP checking works right.
<br>
But... What if both the good and the bad guy are behind the same masqueraded gateway / firewall? They will have the same IP address then.

Okay well that's a potential problem in this day and age but one I haven't had to worry too much about due to the nature of the things I've worked on.
<br>
<br>
In any case, the next stop is to store some (pseudo)random data in the cookie as well and compare that with a known record. The chances of someone guessing this and having the same IP are negligable.
<br>
<br>
If you're really worried you can increase the length of this data to make the chances of some random chancer guessing it as close to 0 as you could reasonably expect. As the user doesn't have a hand in producing this there's actually no reason not to do this in any case.

While the session support is welcome, and a good thing, it is still not a real "session layer" as required for heavy duty work. For instance, you need to either have only one web server box (if using shared memory) or an low page view rate (if using a database) to effectively use either PHPLIB or PHP4's inherent implementations of sessions. I believe PHP4's is somewhat "pluggable" so you could put a different implementation below it (which would be fantastic, and I'd like to see that covered in another article).
What I mean by all of this, is that if you're getting many millions of logged in hits a day, to a large server farm, the overhead to keep retrieving the state data from any shared resource like a DB (esp. oracle or the like) is enormous without specialized [expensive if commercial] caches.
We've developed some in-house solutions, but they're still not great. Something akin to a BEA's WebLogic session stuff, but interfaced to PHP4. Basically, you need a fault-tolerant, extremely high-performance state manager, hopefully with persistence (nice but not completely necessary) but able to handle high volumes of requests... and perhaps work over UDP... and run on boxes with huge memory spaces... etc.
That, plugged into PHP4's session code, would be fantastic.

I've another problem with sessions. How can I automaticly destroy session data. Of course I can use session_destroy(), but what happend if client just close his browser ?
The session data still alive :((...

Does the session support in PHP4 cope with objects? If not, why not? Its pretty important when many people's advanced code such as shopping baskets, store their data in objects.

Hi everybody,
I was the first to ask the question that triggered all the valuable comments entered for this article. I see that it helps us all.

After my investigation I (if am not wrong) found that you can define how long the sessions (and hence the session files in your session files save path) will live before becoming garbage. After that time is it regarded as garbage and will be automatically deleted by the garbage collecter (this is what gc stands for I thinh).

Well, as to what is garbage collecter (a program? , a process?, a code fragment hidden in the session_start() procedure?, I don't know) I really have no idea. But I know that:

1) You will define this session life span (in seconds) in php.ini file using the parameter gc_maxlifetime (something like that...)

2) You have the ability to define how often the magic garbage collecter will fire and delete all the expired session files (this is the answer to your question milczek). This point is not clear to me yet but I think the parameter gc_probability is a percent value and SAYS THAT EVERY THAT PERCENT OF THE SESSION START OPERATIONS, START THE GARBAGE COLLECTER. I could not write it clearly I know, to give examples:
- if parameter is 50, then at every two session_start() call, the garbage collecter will fire
- if parameter is 100, then for every session_start() call, the garbage collecter will fire
- if parameter is 5, then at every 20 session_start() call, the garbage collecter will fire

I wish I am not wrong.

Hope it will help anybody.

Objects and arrays in PHP need to be serialized before you store them to disk (or in a web server). Check out:
<br>
http://www.php.net/manual/function.serialize.php3
<br>
http://www.php.net/manual/function.unserialize.php3
<br>
<br>

A "session cookie" sometimes refers to a cookie which is set to disappear as soon as the user closes his browser. Other times, people use the phrase to refer to any cookie which tracks a user-session. Often, a session cookie of the second type (used to track session data) is also a cookie of the first type (disappears when browser closes).
<br>
<br>
You're correct to be concerned, though: if your session tracking system depends on cookies, and the client's browser has disabled them, you're out of luck.
<br>

I'm afraid that that won't really do. Some ISPs keep changing a surfer's IP number during a session (AOL does this for instance). I don't think there's a very simple way of doing this. Checking other information from the surfer like the referrer and the browser would also help but I think the most important thing is to have a long session id to dramatically reduce the chance of somebody guessing the session ids in the first place.

Hello all,
I just wanted to share my small experiences about
php4 sessions with you. I am playing with sessions and my
own session handling class for a couple of days.

What I found while coding was interesting (at least to me).

For the rest of what I will try to share with you, assume that
a session is created successfully.Also assume that $var1 and
$var2 were registered successfully. You can see that they are
registered by checking the session file manually.

What I want is to start the session and access these variables
in my code. Due to the nature of my program I did not call
sessin_start() in the main body of the called php file. It is called
in a function.

Well, here are what I noticed. (What I experienced may be due to
my faults, config error, or even not an error at all. But just
keep in one side of your head that if you have any trouble with
sessions programming, one of these may be the reason)

NOTE 1

The variables will not be printed
(Even when $var1 and $var2 are defined as global in func1())


NOTE 2

The variables will not be printed
(Even when $var1 and $var2 are defined
as global in func1() and/or func2())



NOTE 3

The variables will BE PRINTED(normal I think..)



NOTE 3

The variables will BE PRINTED
(WILL NOT BE PRINTED IF GLOBAL DEFINITIONS ARE
NOT EXPLICITLY MADE)



I wish they will also sound interesting to you.

Sorry for my previous unreadible message. Here I try it again.
<br>
<br>
<br>
Hello all,<br>
I just wanted to share my small experiences about<br>
php4 sessions with you. I am playing with sessions and my <br>
own session handling class for a couple of days. <br>
<br>
What I found while coding was interesting (at least to me). <br>
<br>
For the rest of what I will try to share with you, assume that<br>
a session is created successfully.Also assume that $var1 and<br>
$var2 were registered successfully. You can see that they are <br>
registered by checking the session file manually.<br>
<br>
What I want is to start the session and access these variables<br>
in my code. Due to the nature of my program I did not call<br>
sessin_start() in the main body of the called php file. It is called <br>
in a function. <br>
<br>
Well, here are what I noticed. (What I experienced may be due to<br>
my faults, config error, or even not an error at all. But just<br>
keep in one side of your head that if you have any trouble with<br>
sessions programming, one of these may be the reason)<br>
<br>
NOTE 1<br>
<br>
The variables will not be printed <br>
(Even when $var1 and $var2 are defined as global in func1())<br>

<!-- Code -->
<p><pre><font color=#008000><xmp>
<?php

function func1(){

start_session();

echo $var1."-".$var2

}

func1(); // Call the function to start the session and print the
// session variables

?>
</xmp></font></pre><p>
<!-- Code -->

NOTE 2

The variables will not be printed
(Even when $var1 and $var2 are defined
as global in func1() and/or func2())

<!-- Code -->
<p><pre><font color=#008000><xmp>
<?php

function func1(){

start_session();

}

function func2(){

func1(); // Start the session
echo $var1."-".$var2
}

func2(); // Do all

?>
</xmp></font></pre><p>
<!-- Code -->

NOTE 3

The variables will BE PRINTED(normal I think..)

<!-- Code -->
<p><pre><font color=#008000><xmp>
<?php

function func1(){

start_session();

}

func1();
echo $var1."-".$var2

?>
</xmp></font></pre><p>
<!-- Code -->

NOTE 3

The variables will BE PRINTED
(WILL NOT BE PRINTED IF GLOBAL DEFINITIONS ARE
NOT EXPLICITLY MADE)

<!-- Code -->
<p><pre><font color=#008000><xmp>
<?php

function func1(){

start_session();

}

function func2(){
global $var1;
global $var2;

echo $var1."-".$var2

}

func1();
func2();

?>

</xmp></font></pre><p>
<!-- Code -->


I wish they will also sound interesting to you.

Well the thing with AOL is that it causes a mess of pages anyway. Like you suggest a longer session ID would perhaps help matters along somewhat.