views:

142

answers:

2

I've been developing a quite "big application" with PHP & kohana framework past 2 years, somewhat-successfully using my framework's authentication mechanism. but within this time, and as the app grown, many concerning state-preservation issues arisen.

main problems are that cookie-driven sessions:

  • can't be used for web-service access ( at least it's really not nice to do so.. )
  • in many cases problematic with mobile access
  • don't allow multiple simultaneous apps on same browser ( can be resolved by hard trickery, but still.. )
  • requires many configurations and mess to work 100% right, and that's without the --browser issues ( disabled cookies, old browsers bugs & vulnerabilities etc )

many other session flaws stated in this old thread : http://lists.nyphp.org/pipermail/talk/2006-December/020358.html

After a really long research, and without any good library/on-hand-solution to feet my needs, i came up with a custom solution to majority of those problems .

The solution i thought about is not using cookies (for statefullness) . instead emulating it by passing back & forth a session-token through the ajax requests. For security, the session token is regenerated on each request. Also, a fingerprint (referrer, OS, clientVer ) is saved on session creation, and validated on each request.

From the first glance that supposed to be not-less-secure than equivalent cookie-driven implementation, and at the same time it's simple, maintainable, and resolves all the cookies flaws.. But i'm really concerned because i often hear the rule "don't try to implement custom security solutions".

I will really appreciate any serious feedback about this method, and any alternatives.

  • also, any tip about how to preserve state on page-refresh without cookies would be great :) but thats small technical prob.

  • Sorry if i overlooked some similar post.. there are billions of them about sessions .

Big thanks in advance ( and for reading until here ! ).

A: 

I think the simplest way it's by using anyway the php session technology but without cookies. To archive this result you need just few php functions, but you must send one more var to every GET request.

session_start();
if(isset($_GET['SESSIONID']))
{
    session_id($_GET['SESSIONID']);
}
echo "<script>var SESSIONID = '".session_id()."';/script>"; 
//session_id() autogenerates a new hash for every new session but you can you the algorithm that you prefer.

Ok, now in every JS script you have your session id, so you only need to append to the url.

Cesar
I see no difference from appending the token to the ajax-call parameters.
The main problem here is not the serverside-session-storage ( there are tones of solutions ), but the cookies. and i'm glad you agree with me about not using cookies at all .
+1  A: 

about preserving session token on page refreshes / unintended back/next -> found a great solution : http://www.sitepoint.com/blogs/2009/09/03/javascript-session-variable-library/ it's cross-browser and allows multiple simultaneous logins ( from different tabs/windows ).