<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Hi,<br>
if I understand right, @InterceptedCall is a _client_ side
interceptor, so I would not spend too much effort there :-)<br>
Summarizing our experience concerning security w/ Errai-Bus:<br>
- only server side security means _security_<br>
- "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<br>
- Errai-Bus is to be regarded as "outside" of container
security context, because:<br>
- communication shall _normally_ not be prohibited by
security - see Bus setup, Login-message<br>
- once a message is received, it will be executed<br>
- 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..<br>
- 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" :)<br>
<br>
Regards,<br>
Thomas<br>
<br>
Am 01.05.2013 16:37, schrieb Rodney Russ:<br>
</div>
<blockquote
cite="mid:CAFFkHdCoyM+ztULn3stmzurkpN6VC1CSz4aE3sU22pgLGXC=vQ@mail.gmail.com"
type="cite">
<p dir="ltr">As I understand it, the PicketLink Core library is
an annotation driven security model. Can it be applied here? </p>
<p dir="ltr">-Rodney</p>
<div class="gmail_quote">On Apr 30, 2013 11:57 AM, "Christian
Sadilek" <<a moz-do-not-send="true"
href="mailto:csadilek@redhat.com">csadilek@redhat.com</a>>
wrote:<br type="attribution">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">Hi,
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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).</div>
<div><br>
</div>
<div>Of course, nothing stops from extending this concept
further….</div>
<div><br>
</div>
<div>Cheers,</div>
<div>Christian</div>
<div><br>
</div>
<div><br>
<div>
<div>On 2013-04-30, at 1:15 PM, Erik Jan de Wit <<a
moz-do-not-send="true"
href="mailto:edewit@redhat.com" target="_blank">edewit@redhat.com</a>>
wrote:</div>
<br>
<blockquote type="cite">
<div style="word-wrap:break-word">Hi Guys,
<div><br>
</div>
<div>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:</div>
<div><br>
</div>
<div>
<div>@Retention(RetentionPolicy.RUNTIME)</div>
<div>@Target({ElementType.TYPE,
ElementType.METHOD})</div>
<div>@InterceptedCall(SecurityInterceptor.class)</div>
<div>public @interface RequireAuthentication {</div>
</div>
<div>}</div>
<div><br>
</div>
<div>and have the SecurityInterceptor invoked the
only way I can do it is by annotating the methods
with:</div>
<div><br>
</div>
<div>@InterceptedCall(SecurityInterceptor.class)</div>
<div><br>
</div>
<div>Why now have it more like the CDI interceptor
api <a moz-do-not-send="true"
href="http://docs.oracle.com/javaee/6/api/javax/interceptor/InterceptorBinding.html"
target="_blank">http://docs.oracle.com/javaee/6/api/javax/interceptor/InterceptorBinding.html</a></div>
<div><br>
</div>
<div>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?</div>
<div><br>
</div>
<div>Cheers,</div>
<div><span style="white-space:pre-wrap"> </span>Erik
Jan</div>
</div>
_______________________________________________<br>
errai-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:errai-dev@lists.jboss.org"
target="_blank">errai-dev@lists.jboss.org</a><br>
<a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/errai-dev"
target="_blank">https://lists.jboss.org/mailman/listinfo/errai-dev</a></blockquote>
</div>
<br>
</div>
</div>
<br>
_______________________________________________<br>
errai-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:errai-dev@lists.jboss.org">errai-dev@lists.jboss.org</a><br>
<a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/errai-dev"
target="_blank">https://lists.jboss.org/mailman/listinfo/errai-dev</a><br>
</blockquote>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
errai-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:errai-dev@lists.jboss.org">errai-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/errai-dev">https://lists.jboss.org/mailman/listinfo/errai-dev</a></pre>
</blockquote>
<br>
</body>
</html>