<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 9, 2014 at 9:58 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 2014-10-09, Matthias Wessendorf wrote:<br>
> On Thu, Oct 9, 2014 at 6:04 PM, Sébastien Blanc <<a href="mailto:scm.blanc@gmail.com">scm.blanc@gmail.com</a>> wrote:<br>
><br>
> > Another option could be :<br>
> > - no change or addition of any endpoint<br>
> > -no change on the angular side<br>
> ><br>
> > Since the result is the same : we want a list of applications (for admin<br>
> > there is just no restriction on developer that owns it)<br>
> > But in the service layer when retrieving the applications we check the<br>
> > role (do we have a method hasRole(string) ? ) to see if we add the criteria<br>
> > of developer.<br>
> ><br>
><br>
> yeah, that;s what I had in my email from last night as well. the service<br>
> returns a list of applications.<br>
<br>
</span>I think this is very clear to everyone and the basic principle of this<br>
jira.<br>
<span class=""><br>
> Inside we handle the different cases:<br>
> - admin<br>
> Select all (e.g. "select pa from PushApplication pa")<br>
> -developer<br>
> select 'my apps' (e.g. "select pa from PushApplication pa where<br>
> pa.developer = :loginName")<br>
<br>
</span>This is the recommendation from KC documentation<br>
<a href="http://docs.jboss.org/keycloak/docs/1.0.2.Final/userguide/html/ch07.html#d4e611" target="_blank">http://docs.jboss.org/keycloak/docs/1.0.2.Final/userguide/html/ch07.html#d4e611</a>.<br></blockquote><div><br></div><div>I understand their example, but we don't really (within UPS) have a completely different UI between "admin" and "developer" roles.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
So what do you guys suggest is: If I have several methods to validate<br>
multiple roles, just add if/else all along the UPS code? And if I have a new<br>
role, include more ifs?<br>
<br>
I think it can be done inject the SecurityContext, have to check with<br>
Stian and Bill. But it doesn't seem right.<br></blockquote><div><br></div><div>might not be the most elegant, but looks like it avoids adding too much new code. Especially since the UI for 'admin' and 'developer' is pretty much the same.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
><br>
><br>
> -Matthias<br>
><br>
><br>
><br>
><br>
><br>
> ><br>
> > Envoyé de mon iPhone<br>
> ><br>
> > > Le 9 oct. 2014 à 17:45, Bruno Oliveira <<a href="mailto:bruno@abstractj.org">bruno@abstractj.org</a>> a écrit :<br>
> > ><br>
> > > Good morning, moving forward with<br>
> > > <a href="https://issues.jboss.org/browse/AGPUSH-1036" target="_blank">https://issues.jboss.org/browse/AGPUSH-1036</a>. What is the most<br>
> > > recommended approach for admin-ui.<br>
> > ><br>
> > > Have separated endpoints for the admin like:<br>
> > ><br>
> > > 1.<br>
> > ><br>
> > > @RolesAllowed("admin")<br>
> > > @Path("/admin/applications")<br>
> > > public class AdminApplicationEndpoint extends AbstractBaseEndpoint {<br>
> > ><br>
> > > @GET<br>
> > > @Produces(MediaType.APPLICATION_JSON)<br>
> > > public Response listAllPushApplications(){<br>
> > > //queries<br>
> > > }<br>
> > > }<br>
> > ><br>
> > > Or introduce a new method inside the current PushApplicationEndpoint:<br>
> > ><br>
> > > 2.<br>
> > ><br>
> > > @GET<br>
> > > @Produces(MediaType.APPLICATION_JSON)<br>
> > > @RolesAllowed("admin")<br>
> > > public Response listAllPushApplications(){<br>
> > > //queries<br>
> > > }<br>
> > > // READ<br>
> > > @GET<br>
> > > @Produces(MediaType.APPLICATION_JSON)<br>
> > > public Response listAllPushApplicationsByUsername(@Context<br>
> > HttpServletRequest request) {<br>
> > > return<br>
> > Response.ok(pushAppService.findAllPushApplicationsForDeveloper(extractUsername(request))).build();<br>
> > > }<br>
> > ><br>
> > ><br>
> > > If the option 2 is the correct. How the Angular.js service would look<br>
> > > like? Once the username is not informed as argument on<br>
> > > pushApplicationService.js, because for obvious reasons it can be<br>
> > > retrieved with HttpServletRequest.<br>
> > ><br>
> > > One of my poor ideas due to my "amazing" Angular skills would be to do<br>
> > > something like:<br>
> > ><br>
> > > @GET<br>
> > > @Produces(MediaType.APPLICATION_JSON)<br>
> > > @RolesAllowed("admin")<br>
> > > @Path("/all")<br>
> > > public Response listAllPushApplications(){<br>
> > > //queries<br>
> > > }<br>
> > ><br>
> > > And:<br>
> > ><br>
> > > backendMod.factory('pushApplication', function ($resource) {<br>
> > > return $resource('rest/applications/all/:verb', {<br>
> > > .....<br>
> > ><br>
> > ><br>
> > > Help?<br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > > --<br>
> > ><br>
> > > abstractj<br>
> > > PGP: 0x84DC9914<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>
> ><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>
> ><br>
><br>
><br>
><br>
> --<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><br>
<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>
<br>
<br>
--<br>
<br>
abstractj<br>
PGP: 0x84DC9914<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></div></div></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></div>