On Sep 15, 2009, at 11:41 , Patrick Ohly wrote:
One thing you can do (as a server) is to request auth not only for
the
first message, but again for every subsequent one (by responding 200
in the SyncHdr status, and not 212 as usually done). Together with
MD5
auth and https, I think this is waterproof, because in the non-
interceptable SSL response you have the nonce you need to succeed
with
MD5 auth for the next message.
Yes, looks much better than the current approach. But will all clients
support it? From what I remember about the Funambol library, I very
much
doubt that it would cope with such a server behavior.
I think it is a MUST in the standard, and if I correctly remember it
was even tested by SCTS (the SyncML initiative's test suite tool of
the old days - every participant in a SyncFest had to pass SCTS as
part of the registration).
But I admit I haven't tested this recently, neither with our own
implementation nor foreign ones.
It's good to have this in mind though for Synthesis<->Synthesis syncs.
Does the Synthesis engine create the number itself?
Yes.
Then the next question is: how is encoding the number inside the
RespURL
handled? What I'm aiming at is, how does the server know that it
should
append "?sessionid=<number>" to the base URL? This might work for
HTTP,
but other transports might require different methods to tell the
client
about the session ID.
Correct. The way this is formatted (or added at all - AFAIK other
transports don't need it anyway, because they have a transport level
session concept) is transport specific.
Therefore, in libsynthesis_srv, providing the RespURI (or the parts of
it that are transport specific, I'm working on the details) will be
something the app will need to do.
Lukas Zeller (l...@synthesis.ch)
-
Synthesis AG, SyncML Solutions & Sustainable Software Concepts
i...@synthesis.ch, http://www.synthesis.ch
_______________________________________________
os-libsynthesis mailing list
os-libsynthesis@synthesis.ch
http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
