Re: session management with database: optimal parameters in php.ini

phicarre schreef:
On 3 mar, 19:00, Erwin Moller
<Since_humans_read_this_I_am_spammed_too_m...@xxxxxxxxxxxxxxxx> wrote:
phicarre schreef:

I am developping one script for the "session management with database"
and I would like to know which parameters I must change in php.ini
according to these requirements:
- I am using the session_set_save_handler() function
good.

- I don't know if the client side uses or not the cookies
And you shouldn't care either. PHP will pass the sessionid to your
functions you use in session_set_save_handler().

- Several clients can access in the same time to the web application
That is normal.
They all have a different sessionid, so that is fine.

- The web application shall be secured against classical attacks
Meaning what excactly?

I wrote a few db-sessionstorage routine, and here a some things I would
have liked to know before. ;-)

1) Make sure you handle concurrency adequately in your routines.
If you finish the sessionhandling in the db, make a simple testpage to
test concurrency:
a) Make a htmlpage with 20 frames.
b) Put in every frames testdb.php
c) testdb.php does something like this:
<?php
// your initstuff
if (isset($_SESSION["count"])){
$_SESSION["count"] = $_SESSION["count"] + 1;
} else {
$_SESSION["count"] = 1;
}
echo $_SESSION["count"];
?>

Now go to that framed page in your browser: The result would be a
htmlpage with 20 frames that all hold different numbers (not necessarely
all in order.)

2) Make sure you protect yourself against SQL-inject attacks.
Mind that the sessionid comes from the client, thus it can be tampered
with. It might contain:
1'); DELETE FROM tblusers;

which you don't want to use in your query:
SELECT sessiondata FROM tblusers where (sessionid=$sessionid);

So normal paranoia applies here.

3) If you need inspiration:
a) ADODB (a database abstractionlayer) has a build-in sessionmanagement
module for database, written in PHP.http://www.phplens.com/adodb

4) If you use Postgres (which is a great database), you might have a
look at:http://nl.php.net/manual/en/book.session-pgsql.php

Good luck!

Regards,
Erwin Moller

--
"There are two ways of constructing a software design: One way is to
make it so simple that there are obviously no deficiencies, and the
other way is to make it so complicated that there are no obvious
deficiencies. The first method is far more difficult."
-- C.A.R. Hoare

Thank you for your answers.
Your first point is interesting because I don't know how to test
sessions for an multiusers environment. I don't understand "Make a
htmlpage with 20 frames". Could you explain for Firefox ...
If the test is compliant, can I conclude that I won't have problems
with multiple accesses ?

Hi,

My suggested test isn't testing multiuser environment.
It is testing access to the SESSION by the same person with high speed access to the session.

Some background:
Your sessionlogic should BLOCK the executing script untill that script can 'get' the session for itself alone.

The reason behind this is simple if you think about it: You don't want to have 2 scripts (of two instances of the same script) using the same session at the same time.
That will give a mess sooner or later. Script1 is writing stuff to the session, script 2 is deleting other stuff at the same time.
What is the way the session is left behind at the server then?

So you sessionlogic should at least:
1) Handle concurrent request by different users (=different PHPSESSID) correctly.
2) Handle concurrent request by the same user (=same PHPSESSID) correctly.

Point 1 isn't that difficult since you are manipulating the database for a certain PHPSESSID, which is different in this case.

Point 2 is harder (in my experience).
So to test this I suggested a 20 frame-test.
Your browser will send requests for all 20 pages to the server at the same time.

Here is a short example:
1) First make a page that starts a session, eg start.php
Create the sessionvariable "count".

<?php
session_start();
$_SESSION["count"] = 1;
?>
<HTML>
<HEAD>
<TITLE>concurrency test</TITLE>
</HEAD>
<BODY>
<a href="frametest.html">Go to frametest</a>
</BODY>
</HTML>

Also make a hyperlink that sends you to frametest.html

2) in frametest.html you simply put:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN"
"http://www.w3.org/TR/html4/frameset.dtd";>
<HTML>
<HEAD>
<TITLE>concurrency test</TITLE>
</HEAD>
<FRAMESET rows="5%">
<FRAME src="phpsessiontest.php">
<FRAME src="phpsessiontest.php">
<FRAME src="phpsessiontest.php">
.... and 17 more...
</FRAMESET>
</HTML>

3) In phpsessiontest.php you manipulate the "count" in session, eg:
<?php
session_start();
$_SESSION["count"] = $_SESSION["count"] + 1;
// spend some time, sleep 1 second
sleep(1);
echo $_SESSION["count"];
?>

Now, if you go to the first page, you have a session with your server.
If you click the link to frametest.html, this happens:
- Your browser receives the HTML with the frameset in it
- Your browser sends out 20 requests to the server to get the HTML to fill the frames. So it requests 20 times phpsessiontest.php.
- These requests arrive at the server roughly at the same time in some order (which is unrelevant to the problem)
- Say request5 arrives first: Now phpsessiontest.php is executed at the server. This php file starts with session_start();
Then is goes asleep for 1 second.
During this second some other requests arrive, and want to start phpsessiontest.php as requested.
They should WAIT untill Request5 finishes its execution.

So the result for you should be: 20 frames that fill one by one with an increasing number: 2, 3, 4, etc.

Note: In this example I am using the same script (phpsessiontest.php) for each frame. This might add some confusion. So for clearities sake: You can also use 20 different scripts that all use the session. The point is that session_start() should block if the session isn't released by another script.

Note2: My number 20 is totally arbitrary.

Point 2: I am aware of that !

Good.

Point 4. I am using mySQL

Shame. ;-)

I hope this example was clearer.

Good luck!

Regards,
Erwin Moller

PS: If you want to debug your sessionlogic, you'll find this can be very difficult. A few functions will NEVER produce any output to the server, because they are activated AFTER the stream of data to the browser is closed.
So if you need to debug I advise you to write your debugdata to a file instead, and read that one.

--
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult."
-- C.A.R. Hoare
.

Relevant Pages