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(a)redhat.com
<mailto:csadilek@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(a)redhat.com
<mailto:edewit@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....
>
> 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(a)lists.jboss.org <mailto:errai-dev@lists.jboss.org>
>
https://lists.jboss.org/mailman/listinfo/errai-dev
_______________________________________________
errai-dev mailing list
errai-dev(a)lists.jboss.org <mailto:errai-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/errai-dev
_______________________________________________
errai-dev mailing list
errai-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/errai-dev