[errai-dev] interceptors

[Erik Jan de Wit]

Hi,

> 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

No that would be very stupid...

>>>     - 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_.

I wasn't suggesting not to use PicketLink why reinvent the wheel when we have something that is tested and used by a lot of other projects. But I agree with you, to make it work with Errai we have some integration work that we have to do. And have a long hard look at how security is now handled by the bus.

Cheers,
	Erik Jan