[sync] progress on session issues

Karsten Fourmont fourmont at gmx.de
Sat Apr 30 02:15:19 PDT 2005


Hi,

I think (hope) I've solved the weird session issue. For those not 
interested in the technical details: do a cvs update or add the 
following lines to rpc.php. Then give the sync4j connector another try. 
Thanks everybody for the feedback.

Index: rpc.php
===================================================================
RCS file: /repository/horde/rpc.php,v
retrieving revision 1.34
diff -r1.34 rpc.php
30a31
 >         $GLOBALS['session_control'] = 'none';

Here are the details:

I'm still not totally clear what has been going wrong but my assumptions 
were good enough to come up with a fix.

The SyncML code does it's own session handling as session cookies or URL 
GET vars are not part of the syncml spec and thus the horde default 
session mechanism does not work.

However unless told otherwise horde automatically creates a session when 
you include lib/base.php (which creates the registry).
That wasn't a problem until recently: SyncML.php::getStateFromSession() 
just destroyed the horde session and created it's own one.
But with the latest sync4j to support cookies, the session created by 
horde is already the "right" one. Then somehow the "session switching" 
does not work properly any more.

Actually I don't know whether this is a sync4j issue at all: it could 
also be that PHP's session handling has somehow changed. I ugraded my 
box to suse 9.3 a few days ago and got a new php version 4.3.10.

Whatever the reasons are, the fix is rather simple: tell horde not to 
create the session for us.

This must be done in rpc.php before lib/base.php is included. The patch 
is in cvs by now.

So it should work for now. However to get this production ready, this 
need to be reviewed once more:

every session needs a unique ID. Normally this is done by a random value 
or timestamp. As the normal session id exchange mechanisms (cookies, url 
get) do not work for syncml.

There's an SyncML element <SessionID> but it's pretty much useless as 
it's defined by the _client_.

So our code creates the session id based on the device ID 
"<Source><LocURI>" in the Sync header. For a p800/900 that's the phones 
unique IMEI id which is ok. But for sync4j it's what you put into the 
device ID textbox, wjocj defaults to sc-pim-outlook. So when different 
users use the sync4j connector with the horde server at the same time, 
they get the same session id! And that will cause major major problems 
of course.
The username can't be part of the session id as it's not sent by syncml 
on any but the first message.

The solution is to use the cookie session mechanism where possible. 
Problem is: that's device dependant behaviour and should be in the 
proper Device subclass. But we need to decide on cookies at a time in 
the xml event flow where we don't have sufficient info yet to determine 
which device we're actually dealing with...

Getting this right needs another step in refactoring which I plan to do 
anyhow:
move away from the "process events as they appear in the xml event flow"
and go to "first collect all the data from XML and then have a central 
controller class take appropriate action based on the data".

This way the business logic would be nicely put in one place (the 
controller class) where it's way easier to maintain then now where the 
logic is cluttered around various beginTag/endTag handlers.

With that in place the controller has all the information when he starts 
creating output and can so decide whether cookies are fine or not.

The SAX like event flow mechanism we currently have is normally chosen 
because it's more memory efficent. That applies to J2EE servers but not 
for PHP scripts.

Thank you for reading this far ;-)

Cheers
  Karsten



More information about the sync mailing list