<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 10, 2014 at 3:20 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">Well it's your call, even if I don't like the design.<br></blockquote><div><br></div><div>perhaps we do a little hangout ?</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>
On 2014-10-10, Matthias Wessendorf wrote:<br>
> On Thu, Oct 9, 2014 at 9:58 PM, Bruno Oliveira <<a href="mailto:bruno@abstractj.org">bruno@abstractj.org</a>> wrote:<br>
><br>
> > 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>><br>
> > 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<br>
> > 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<br>
> > 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>
> > I think this is very clear to everyone and the basic principle of this<br>
> > jira.<br>
> ><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>
> > This is the recommendation from KC documentation<br>
> ><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>
> > .<br>
> ><br>
><br>
> I understand their example, but we don't really (within UPS) have a<br>
> completely different UI between "admin" and "developer" roles.<br>
><br>
><br>
> ><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<br>
> > 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>
> ><br>
><br>
> might not be the most elegant, but looks like it avoids adding too much new<br>
> code. Especially since the UI for 'admin' and 'developer' is pretty much<br>
> the same.<br>
><br>
><br>
> ><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<br>
> > é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>
> > > ><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<br>
> > 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><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>