Am 02.05.2013 08:39, schrieb Erik Jan de Wit:
> Hi,
>
> On May 2, 2013, at 8:23 AM, Thomas Frühbeck <[email protected]> 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
_______________________________________________
errai-dev mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/errai-dev
