[errai-dev] interceptors

Thomas Frühbeck fruehbeck at aon.at
Thu May 2 03:55:55 EDT 2013


Am 02.05.2013 08:39, schrieb Erik Jan de Wit:
> Hi,
>
> On May 2, 2013, at 8:23 AM, Thomas Frühbeck <fruehbeck at aon.at> wrote:
>
>> Hi,
>> if I understand right, @InterceptedCall is a _client_ side interceptor, so I would not spend too much effort there :-)
> >From my perspective it's like validation of the model if we can already do something on the client side we should do it there, but because this can be bypassed we cannot rely on it and have to do this on the server as well. And like you mention we can use CDI interceptors for this.
>
>>      - "logged in" is a conception, which is most critical server side, the client may not know about current state - checking client side won't really help
> Why is it not allowed for the client to know about the current state? Can't I have something like hello #username on my page?
sure you are "allowed" :) - cross cutting concerns (like security) 
require IMHO a consistent/clear/stable handling, you would not clutter 
_every_ RPC call with a "am I logged in".
The problem is, that the server may anytime decide to cancel the session:
     - the client will not notice until trespassing - which could be any 
call at any time, depending on server side business logic
     - you do _definitely not_ want to have the password linger around 
in your client app for later re-use
>>      - Errai-Bus is to be regarded as "outside" of container security context, because:
>>          - communication shall _normally_ not be prohibited by security - see Bus setup, Login-message
>>          - once a message is received, it will be executed
> Could you elaborate on this? What do you suggest that we do?
short wrap-up of what we tried:
     - Errai Authentication: sorry, I evidently didn't understand how to 
handle the async events and bridge that with e.g. EJB3 Security, 
SeamSecurity, container based security, perhaps an unfortunate lack of 
know how - hindlooking we just started on the wrong foot?
     - Container Based Security: wont work, because it relies on 
JSESSIONID cookie, the same being used by the bus (right?), so 
Session.invalidate() means to interrupt the bus
     - frameworks like PicketLink are versatile, tested, powerful, 
annotation driven, easy to apply, best practice - that's what we settled 
with and it _works_.

Personal conclusion: Errai is _more_ than a simple web client, forget 
"security-constraint" in web.xml and blah.. (which is IMHO crap anyway)
We ended up with:
     - a (simple) client side "ProgressInterceptor" handling cross 
cutting concerns like: timeout, modality of UI, redirection on security 
exception
     - server side org.jboss.seam.security.SecurityInterceptor in 
beans.xml and  any relevant bean applied Seam @LoggedIn, etc.
     - login/logout service - yes, nearly the same as Errai 
Authentication, see above, hindlooking blah..
     - authentication by SeamSecurity (brings PicketLink, JAAS, powerful 
role/permission managent) - perhaps later exchange with DeltaSpike? No 
problem!

Best Practice? I'm not sure :) But man, I am happy that it works 
reliably, that's a stack you won't starve on easily.

Comments welcome!!!

Regards,
Thomas



More information about the errai-dev mailing list