<div dir="ltr">excuse me, but how does that related to the roles and structure that we discuss in THIS thead ? <div><br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Nov 7, 2013 at 1:33 PM, Stefan Miklosovic <span dir="ltr"><<a href="mailto:smikloso@redhat.com" target="_blank">smikloso@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-size:12pt;font-family:times new roman,new york,times,serif"><div><pre style="word-wrap:break-word;white-space:pre-wrap">
<span style="font-family:'times new roman','new york',times,serif">Hello,<br><br>when I was doing some REST endpoints and I was trying to test that with APE and Arquillian, I would like to see this one in the action:<br>
<br>Given:
I have this class
@Secure( { "admin" })
public class SomeClass {
public void theFirstMethod() {
}
@Secure({ "developer" })
public void theSecondMethod() {
}
}
When:
I am logged in with "developer" role
Then:
I can call theSecondMethod but I can not call theFirstMethod.
Right now, the implementation logic assumes that class level @Secure takes it all, I would expect that class level scope is used when there is not any annotation present on some particular method, otherwise that one on the method level is used.</span></pre>
<div>From the implementation point of view to have the idea:</div><div><pre style="word-wrap:break-word;white-space:pre-wrap"><span style="font-family:'times new roman','new york',times,serif"> @AroundInvoke
public Object invoke(InvocationContext ctx) throws Exception {
Class clazz = ctx.getTarget().getClass();
Method method = ctx.getMethod();
// this will be added
// method beats the class
if (clazz.isAnnotationPresent(Secure.class) &&
method.isAnnotationPresent(Secure.class)) {
authorize(methodMetadata(ctx));
}
// end of adding things
if (clazz.isAnnotationPresent(Secure.class)) {
authorize(clazzMetadata(ctx));
}
Method method = ctx.getMethod();
if (method.isAnnotationPresent(Secure.class)) {
authorize(methodMetadata(ctx));
}
return ctx.proceed();</span></pre></div><div>However it is rather unknow how this fits into your perspective but I have to say that I personally do not like the way how it is done right now.</div><div><br></div><div>
Regards</div><div><br></div><div><span name="x"></span>Stefan Miklosovic<br>Red Hat Brno - JBoss Mobile Platform<br><div><br></div>e-mail: <a href="mailto:smikloso@redhat.com" target="_blank">smikloso@redhat.com</a><br>irc: smikloso<span name="x"></span></div>
<div><br></div><hr><div><div class="h5"><blockquote style="font-size:12pt;border-left-width:2px;border-left-style:solid;border-left-color:#1010ff;margin-left:5px;padding-left:5px;font-family:Helvetica,Arial,sans-serif"><div dir="ltr">
Sorry I don't get your example, why should destroyEverything() also have "simple" annotated? <div><br><div class="gmail_extra"><br><div><br></div><div class="gmail_quote">On Tue, Nov 5, 2013 at 6:03 PM, Bruno Oliveira <span dir="ltr"><<a href="mailto:bruno@abstractj.org" target="_blank">bruno@abstractj.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:#cccccc;border-left-style:solid;padding-left:1ex">But if you are supporting multiple roles, you can't avoid such issue.<br>
<br>For example:<br><br>@Secure({"developer", "simple"})<br>public void destroyEverything(){<br>// access the nuclear reactor<br>}<br><br>So the interceptor will look into this method and say "geez we have<br>
simple role here" and bang!<br><br>What would be the solution for such problem?<br><div><div><br>Sebastien Blanc wrote:<br>> Well, I was thinking of annotating methods, so delete all the thing<br>> will be only for "developer" and "admin"<br>
<br></div></div><span><span color="#888888" style="color:#888888">--<br>abstractj<br><br><br></span></span><br>_______________________________________________<br>aerogear-dev mailing list<br><a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a></blockquote></div></div></div></div><br>_______________________________________________<br>
aerogear-dev mailing list<br><a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a><br><a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a></blockquote>
<div><br></div></div></div></div></div></div><br>_______________________________________________<br>
aerogear-dev mailing list<br>
<a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br></blockquote></div><br><br clear="all"><div><br></div>-- <br>Matthias Wessendorf <br>
<br>blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>
twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a>
</div>