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
> gal...@redhat.com
> twitter.com/galderz
>
> Project Lead, Escalante
> http://escalante.io
>
> Engineer, Infinispan
> http://infinispan.org
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>

_______________________________________________
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Reply via email to