Page 1 of 3
ways of maintaining HTTP states without session or coockies
Posted: Fri Oct 05, 2007 3:49 pm
by crazytopu
Hi there,
This is an interesting topic, I am working on a project as per my supervisor's guidelines. He suggested that I look out for options where as connection between pages can be maintained without using PHP sessions or cookies. I have used GET or POST methods but wonder if you know of any other ways to get the same job done.
Much appreciated
Posted: Fri Oct 05, 2007 5:22 pm
by alex.barylski
There are other ways, sure, but the principles are basically the same.
Cookies allow client side persistence, whereas sessions are server side. Instead of using PHP built in sessions support, you could write your own or override the default session storage to use a database instead of files.
Why wouldn't you just use SESSIONS though? I have only worked on maybe a dozen servers which didn't properly have SESSIONS configured, these were window machines which needed slight adjustment.
SESSIONS support is probably available 99.9999% of the time making it almost useless to use any other method.
Why are you required to use something other than?
Posted: Fri Oct 05, 2007 6:16 pm
by RobertGonzalez
The only other remotely reliable way to maintain state between requests is to use a querystring identifier from request to request, then store that identifier somewhere on the server that keys it to certain snippets of the session.
Of course, that is exactly what PHP sessions do, so why you want to reinvent the wheel is beyond me, but that is the essence of it.
Posted: Fri Oct 05, 2007 7:00 pm
by crazytopu
Everah and Hockey,
Thank you guys for your reply. To be honest with you, I have worked with Session and loved it. My supervisor still insist that I use either query string, or hidden html fields to maintain state from request to request. Now, I am seriously thinking of making use of session. But this is a Masters dissertation, my supervisor needs to be convinced (so far he is not so happy with session, he thinks session has a time status, and session variable dies out with time).
He wants a system that allows user to come back and use the same url (given during their order processing ) and they can still view their shopping cart's content no matter how long after they have come back to the site. The url will ideally be on their electronic invoice that they can print out (point is they will have access to the url). I have the restriction of using the database design suggested by him, so not enough freedom to be able to store that url in the given design.
So, this is a bit complicated. I know i cannot convince him to use cookies (big privacy issue) but in support of session and the problem I have mentioned above, if you have any answer, even if a line or two please do not hesitate to post.
Another little thing, anybody would be interested to 'walkthough' my Tinycart API (It is a open source software, one day might possibly be like zen-cart or agora cart)? The API is not long or anything complicated but it's just that I can use this feedback to include in my report writing.
Many Thanks for your help again .
Posted: Fri Oct 05, 2007 7:09 pm
by RobertGonzalez
Sessions do have time limitations, but these can be easily worked through. The lack of security involved in relying on a querystring or form field is astounding. Even suggesting such a thing is odd.
Sessions, at their very core, are either going to set a cookie with the session id or, if the cookie cannot be set, will pass to the querystring the session id so that it is carried throughout the app. But this is really a bad design requirement when there are tools available for this.
And as far as being able to come back anytime you want in the future and see where you were when you left off just by visiting a URL... well that is only going to happen with cookies. Unless you require your users to login, in which case you can store data tied to their login and recall then when they login again.
Good luck with your project. This might not have a happy ending if you stay under the requirements you are under.
Posted: Fri Oct 05, 2007 7:20 pm
by Jenk
The other option is to use a platform that is not request based, such as Java, but even then you'll still need a request variable (be it post, get or cookie) to identify the session.. so in reality, using $_SESSION is not far fetched from using a stateful platform anyway.
Posted: Fri Oct 05, 2007 7:38 pm
by crazytopu
------- Sessions do have time limitations, but these can be easily worked through.
Can you point me to any article?
http://www.developerfusion.co.uk/show/2234/ here is one that discusses about pros and cons of session ..just reading it now.
Posted: Fri Oct 05, 2007 7:55 pm
by feyd
Well.. the garbage collector, by default, kills "stale" sessions. A good thing, and not so good thing.. depending on how stale you wish to allow sessions to get. The default threshold for stale isn't all that long (24 minutes.) ... however the garbage collector only runs every so often.
I prefer to shift sessions to my control. Under a database they are shifted away from file-based, which can be far easier to compromise on improperly set up hosts.
Posted: Sat Oct 06, 2007 5:59 am
by VladSun
Another approach is not to save anything server-side - just pass a serialized "User object" (you can imagine it as passing $_SESSION) in POST and a HMAC of its value, so the user can't modify it.
Posted: Sat Oct 06, 2007 6:01 am
by crazytopu
Hidden HTML field does the same thing, isnot it? User cant edit its value.
Posted: Sat Oct 06, 2007 6:03 am
by VladSun
crazytopu wrote:Hidden HTML field does the same thing, isnot it? User cant edit its value.
He can! That's why you need a second hidden field - the HMAC value - it is the "fingerprint" of your data, generated by using a server-side secret key.
Posted: Sat Oct 06, 2007 6:05 am
by VladSun
An example of HMAC function:
Code: Select all
function hmac($algo, $data, $passwd)
{
/* md5 and sha1 only */
$algo = strtolower($algo);
$p = array('md5'=>'H32','sha1'=>'H40');
if(strlen($passwd) > 64) $passwd=pack($p[$algo], $algo($passwd));
if(strlen($passwd) < 64) $passwd=str_pad($passwd, 64, chr(0));
$ipad = substr($passwd, 0, 64) ^ str_repeat(chr(0x36), 64);
$opad = substr($passwd, 0, 64) ^ str_repeat(chr(0x5C), 64);
return($algo($opad.pack($p[$algo], $algo($ipad.$data))));
}
Posted: Sat Oct 06, 2007 6:08 am
by VladSun
On second thought a single XSS attack success will grant the attacker an eternal successful log in ...
Posted: Sat Oct 06, 2007 6:18 am
by crazytopu
does hidden html have any serious security issue just like query string have?
Posted: Sat Oct 06, 2007 6:40 am
by VladSun
Every client-side information has - it doesn't matter whether it is $_COOKIE, $_GET, $_POST or even some of the fields in $_SERVER. You should treat every user as an attacker.