Hi,
On Feb 27, 2009, at 1:50 PM, Mickael Remond wrote:
Dave Cridland wrote:
On Thu Feb 26 21:40:44 2009, Fabio Forno wrote:
On Thu, Feb 26, 2009 at 5:05 PM, Mickael Remond
<mickael.rem...@process-one.net> wrote:
With the JID you can simply reconnect to the existing running
session
without having another shared state. It makes a big difference
for large scale
deployment with clustering support.
In this stanza?
<resume xmlns='urn:xmpp:sm:0' previd='some-long-sm-id'/>
Do you mean using the full jid instead of the previd or in addition?
If it's just the jid it can work only if the server sets a resource
with some random data, otherwise it becomes extremely easy to
hijack a sesssion
What I suggest is to have both the jid and the session id.
Because the server chooses the sm-id, it can encode the full jid into
it if needs be.
My point was to avoid giving meaning to opaque data.
In my view, "opaque" is applied to the client point of view. I have no
problems that a field, generated by the server, and only used by the
same server (server here could mean a set of servers working together)
has some meaning to it.
I would imagine for example, that I could have a sm-id as ID,HMAC
where I can check if the ID was not tampered with. The sm-id is opaque
to the client and has meaning to the server.
Best regards,
--
Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: m...@simplicidade.org
Use XMPP!
