[sync] progress on session issues

[Roel Gloudemans]

As a sidenote. On the first (slowsync) it doesn't get all (none 
actually) the appointments/contacts from horde. All appointments 
created after the first sync get synchronized however.

Cheers,
Roel.

Quoting Karsten Fourmont <fourmont at gmx.de>:

> 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
>
> --
> sync mailing list - Join the hunt: http://horde.org/bounties/#sync
> Frequently Asked Questions: http://horde.org/faq/
> To unsubscribe, mail: sync-unsubscribe at lists.horde.org
>