[errai-dev] interceptors
Thomas Frühbeck
fruehbeck at aon.at
Thu May 2 02:23:12 EDT 2013
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
More information about the errai-dev
mailing list