[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