[errai-dev] interceptors

[Thomas Frühbeck]

Hi,
if I understand right, @InterceptedCall is a _client_ side interceptor, 
so I would not spend too much effort there :-)
Summarizing our experience concerning security w/ Errai-Bus:
     - only server side security means _security_
     - "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
     - 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
     - modern EE6/CDI interceptors are very easy to apply to service 
beans (that's where they belong according EE), frameworks exist 
(container based security, PicketLink), unconstrained by GWT JRE 
emulation, Errai mapping..
     - it would help to have some set of _RuntimeExceptions_ for typical 
cross cutting concerns like security/validation.. handled naturally by 
the bus - see "no boiler-plate" :)

Regards,
Thomas

Am 01.05.2013 16:37, schrieb Rodney Russ:
>
> As I understand it,  the PicketLink Core library is an annotation 
> driven security model.   Can it be applied here?
>
> -Rodney
>
> On Apr 30, 2013 11:57 AM, "Christian Sadilek" <csadilek at redhat.com 
> <mailto:csadilek at redhat.com>> wrote:
>
>     Hi,
>
>     We could come back to an idea we had a while ago: introducing
>     annotation aliasing or macros (as Mike called it). It would allow
>     us to define an annotation say @UiProperty that means the same as
>     @Inject @Bound @DataField. We could extend that concept to also
>     include annotation values and then define @RequireAuthentication
>     to mean @InterceptedCall(SecurityInterceptor.class). This would
>     mainly be an addition to errai-codegen. The existing generators
>     would stay the same.
>
>     The reason the current interceptor solution is not aligned with
>     CDI is that it focuses on remote calls (which are asynchronous and
>     therefore require a more complex call context for manipulating
>     async results) and that it also needs to work without CDI (say in
>     plain bus apps).
>
>     Of course, nothing stops from extending this concept further….
>
>     Cheers,
>     Christian
>
>
>     On 2013-04-30, at 1:15 PM, Erik Jan de Wit <edewit at redhat.com
>     <mailto:edewit at redhat.com>> wrote:
>
>>     Hi Guys,
>>
>>     What I like in a lot of security frameworks is that one can
>>     secure method calls with a simple annotation. So my idea was that
>>     we could make something like @RequireAuthentication on the remote
>>     interface and that would not allow the call if nobody is logged
>>     in. We could develop something like this based on
>>     the InterceptedCall functionality, but because of the
>>     way InterceptedCall is setup there is no way to make another
>>     annotation behave like InterceptedCall. To make it a bit more
>>     clear i cannot define an annotation like this:
>>
>>     @Retention(RetentionPolicy.RUNTIME)
>>     @Target({ElementType.TYPE, ElementType.METHOD})
>>     @InterceptedCall(SecurityInterceptor.class)
>>     public @interface RequireAuthentication {
>>     }
>>
>>     and have the SecurityInterceptor invoked the only way I can do it
>>     is by annotating the methods with:
>>
>>     @InterceptedCall(SecurityInterceptor.class)
>>
>>     Why now have it more like the CDI interceptor api
>>     http://docs.oracle.com/javaee/6/api/javax/interceptor/InterceptorBinding.html
>>
>>     This gives me the ability to lousily couple the annotation with
>>     the interceptor are there reasons for the model that is
>>     implemented now? Can we change it so that it will be more
>>     flexible? Or shall we stick with how it's is now and extend the
>>     functionality to make it work with my example annotation?
>>
>>     Cheers,
>>     Erik Jan
>>     _______________________________________________
>>     errai-dev mailing list
>>     errai-dev at lists.jboss.org <mailto:errai-dev at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/errai-dev
>
>
>     _______________________________________________
>     errai-dev mailing list
>     errai-dev at lists.jboss.org <mailto:errai-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/errai-dev
>
>
>
> _______________________________________________
> errai-dev mailing list
> errai-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/errai-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/errai-dev/attachments/20130502/55457c77/attachment.html