[RESOLVED] How much info can the $_SESSION superglobal hold??

[Paul_help_]

Hi guys.

I have to ask something.

Lets say I built a website and then wanted to build a login area for an administrator to make changes/updates.

And lets say I wanted to store an array of data in the $_SESSION superglobal named 'adminDetails':

$_SESSION["adminDetails"]

And then, lets say I wanted to add another element inside the $_SESSION superglobal named 'loginDetails':

$_SESSION["loginDetails"]

...... My question is - will the "loginDetails" element replace and therefore delete the "adminDetails" element?

Or will $_SESSION simply hold both elements ready for use?

Paul.

[Weedpacket]

No, they're different elements because they have different keys (see [man]arrays[/man] for a description of how associative arrays behave).

[dalecosp]

And, to answer the original question, $SESSION is limited in size only by memory_limit, which in a default install is 128MB. Of course, that's the limit for the entire script, $SESSION and all.

[sneakyimp]

dalecosp;11061713 wrote:

And, to answer the original question, $SESSION is limited in size only by memory_limit, which in a default install is 128MB. Of course, that's the limit for the entire script, $SESSION and all.

Strictly speaking, the size of your session will depend on the method used to store session data. Some PHP frameworks (e.g., Laravel or CodeIgniter) offer the possibility to use a database table to store session data. In that case, the size limit will depend on how this database table is defined and possibly other factors.

I believe the default PHP setting will create temporary files on your machine's file system. These are less likely to suffer from size limitations on a per-session basis but you may encounter other problems like running out of temporary disk space or something like that.

[dalecosp]

sneakyimp;11061863 wrote:

I believe the default PHP setting will create temporary files on your machine's file system. These are less likely to suffer from size limitations on a per-session basis but you may encounter other problems like running out of temporary disk space or something like that.

"May encounter" ... I guess. Never actually have 😉

Here's some of the relevant gook from the INI file of a typical production box:

session.gc_probability = 1
session.save_handler = files
;session.save_path = "/tmp"
session.gc_divisor = 1000
session.gc_maxlifetime = 1440

So, session data is saved in files located under /tmp. There is a .1% chance that PHP will start a session garbage collection routine for any given run of the interpreter; if run, it will erase session files that haven't been updated in the last 24 minutes.

[sneakyimp]

dalecosp;11061875 wrote:

"May encounter" ... I guess. Never actually have 😉

I have had a server run out of disk space, but it was probably due to a too-small VM (e.g., 8G😎 and log files that were growing without bound and maybe a git repo or something. On the other hand, if you are talking about allowing session data to reach 128MB per user it wouldn't take too many users to hit a few GB pretty fast.

[dalecosp]

sneakyimp;11061893 wrote:

I have had a server run out of disk space, but it was probably due to a too-small VM (e.g., 8G😎 and log files that were growing without bound and maybe a git repo or something. On the other hand, if you are talking about allowing session data to reach 128MB per user it wouldn't take too many users to hit a few GB pretty fast.

Right, but a session hash, userid, and couple of other variables will never be more than a few KB ... right?

[sneakyimp]

dalecosp;11061901 wrote:

Right, but a session hash, userid, and couple of other variables will never be more than a few KB ... right?

Yessir. This script:

session_start();
var_dump($_SESSION);

$_SESSION["userid"] = 1234567890;
$_SESSION["var1"] = "foo|DOH";
$_SESSION["var2"] = "bar";

Has the effect on my workstation of creating the file /var/lib/php5/sess_9c7g1fdirt8hp33jrr04p383o2 because Ubuntu's default session file location is /var/lib/php5. You can see where your system saves session files with this command:

echo session_save_path();

Listing that file, I see that it is 54 bytes:

$ sudo ls -al /var/lib/php5/sess_9c7g1fdirt8hp33jrr04p383o2
-rw------- 1 www-data www-data 54 May 11 10:24 /var/lib/php5/sess_9c7g1fdirt8hp33jrr04p383o2

And its contents look like so:

userid|i:1234567890;var1|s:7:"foo|DOH";var2|s:3:"bar";

I'm kinda puzzled at the serialization format there. That's not your usual output from serialize()

[Weedpacket]

sneakyimp wrote:

I'm kinda puzzled at the serialization format there. That's not your usual output from serialize()

I don't know why [font=monospace]|[/font]s are swapped for [font=monospace]:[/font]s, but the principal differences between the outputs of [font=monospace][man]session_encode/man[/font] and [font=monospace][man]serialize/man[/font] are that the encoded session doesn't bother saying that the session data consists of the elements of an array, and, since [font=monospace]$_SESSION[/font] doesn't do numeric keys, it doesn't bother typing or quoting the names of the keys. Which, incidentally, leads to odd things happening to the session if you have a session element of [font=monospace]"foo|bar"[/font].

<?php
session_start();

$a = (object)['foo' => null];
$b = (object)['bar' => null];

$a->foo = $b;
$b->bar = $a;

$_SESSION['a'] = $a;
$_SESSION['b'] = $b;

echo serialize($_SESSION);
echo "\n\n";
echo session_encode();

a:2:{s:1:"a";O:8:"stdClass":1:{s:3:"foo";O:8:"stdClass":1:{s:3:"bar";r:2;}}s:1:"b";r:3;}
          a |O:8:"stdClass":1:{s:3:"foo";O:8:"stdClass":1:{s:3:"bar";r:1;}}     b |r:2;

Note though, that within each key[font=monospace]|[/font]value pair, the value is serialised normally.
And that this is with the default "php" session.serialize_handler.

[Weedpacket]

As an addendum to my previous post, see https://bugs.php.net/bug.php?id=33786#1388791834