[errai-dev] interceptors

Rodney Russ rdruss at gmail.com
Wed May 1 10:37:04 EDT 2013


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> 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> 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
> 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/20130501/30f60108/attachment-0001.html 


More information about the errai-dev mailing list