Hi Galder,
regarding the "Client Identification" paragraph I was thinking of the
connection there might be with authenticated session ids I describe in
the security document [1] in order to reduce the potential proliferation
of identifiers.
In the "security case" it is the server who is generating a unique
session identifier at the end of a successful auth handshake. Such an
identifier is then sent back from the client for all subsequent requests
to avoid re-authentication. My plan was to tie this session id merely to
the user's principal but this would not allow recognizing a
dropped/restarted client.
My proposal is therefore that the HotRod protocol should add just one
element which can serve both purposes.
Tristan
[1]
https://github.com/infinispan/infinispan/wiki/Security
On 12/05/2013 05:16 PM, Galder ZamarreƱo wrote:
Hi all,
Re:
https://github.com/infinispan/infinispan/wiki/Remote-Hot-Rod-Events
Thanks a lot for the feedback provided in last thread. It was very constructive feedback
:)
I've just finished updating the design document with the feedback provided in the
previous email thread. Can you please have another read and let the list know what you
think of it?
Side note: The scope has got bigger (with the addition of filters/converters), so we
might need to consider whether we want all features in next version, or whether some parts
could be branched out to next iterations.
Cheers,
--
Galder ZamarreƱo
galder(a)redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev