[aerogear-dev] Admin endpoints

[Bruno Oliveira]

Let's do a quick hangout tomorrow to discuss if possible.

On 2014-10-09, Sébastien Blanc wrote:
>
>
> Envoyé de mon iPhone
>
> > Le 9 oct. 2014 à 21:58, Bruno Oliveira <bruno at abstractj.org> a écrit :
> >
> >> On 2014-10-09, Matthias Wessendorf wrote:
> >>> On Thu, Oct 9, 2014 at 6:04 PM, Sébastien Blanc <scm.blanc at gmail.com> wrote:
> >>>
> >>> Another option could be :
> >>> - no change or addition of any endpoint
> >>> -no change on the angular side
> >>>
> >>> Since the result is the same : we want a list of applications (for admin
> >>> there is just no restriction on developer that owns it)
> >>> But in the service layer when retrieving the applications we check the
> >>> role (do we have a method hasRole(string) ? ) to see if we add the criteria
> >>> of developer.
> >>
> >> yeah, that;s what I had in my email from last night as well. the service
> >> returns a list of applications.
> >
> > I think this is very clear to everyone and the basic principle of this
> > jira.
> >
> >> Inside we handle the different cases:
> >> - admin
> >>   Select all (e.g. "select pa from PushApplication pa")
> >> -developer
> >>   select 'my apps' (e.g. "select pa from PushApplication pa where
> >> pa.developer = :loginName")
> >
> > This is the recommendation from KC documentation
> > http://docs.jboss.org/keycloak/docs/1.0.2.Final/userguide/html/ch07.html#d4e611.
> >
> > So what do you guys suggest is: If I have several methods to validate
> > multiple roles, just add if/else all along the UPS code? And if I have a new
> > role, include more ifs?
> >
> > I think it can be done inject the SecurityContext, have to check with
> > Stian and Bill. But it doesn't seem right.
> I agree that our solution implies using some if/else but we have to balance that against having a new method/endpoint for each role + changing the frontend. Don't get me wrong here, I will follow the best practice regarding security/design .
> >
> >>
> >>
> >> -Matthias
> >>
> >>
> >>
> >>
> >>
> >>>
> >>> Envoyé de mon iPhone
> >>>
> >>>> Le 9 oct. 2014 à 17:45, Bruno Oliveira <bruno at abstractj.org> a écrit :
> >>>>
> >>>> Good morning, moving forward with
> >>>> https://issues.jboss.org/browse/AGPUSH-1036. What is the most
> >>>> recommended approach for admin-ui.
> >>>>
> >>>> Have separated endpoints for the admin like:
> >>>>
> >>>> 1.
> >>>>
> >>>> @RolesAllowed("admin")
> >>>> @Path("/admin/applications")
> >>>> public class AdminApplicationEndpoint extends AbstractBaseEndpoint {
> >>>>
> >>>>   @GET
> >>>>   @Produces(MediaType.APPLICATION_JSON)
> >>>>   public Response listAllPushApplications(){
> >>>>       //queries
> >>>>   }
> >>>> }
> >>>>
> >>>> Or introduce a new method inside the current PushApplicationEndpoint:
> >>>>
> >>>> 2.
> >>>>
> >>>>   @GET
> >>>>   @Produces(MediaType.APPLICATION_JSON)
> >>>>   @RolesAllowed("admin")
> >>>>   public Response listAllPushApplications(){
> >>>>     //queries
> >>>>   }
> >>>>   // READ
> >>>>   @GET
> >>>>   @Produces(MediaType.APPLICATION_JSON)
> >>>>   public Response listAllPushApplicationsByUsername(@Context
> >>> HttpServletRequest request) {
> >>>>       return
> >>> Response.ok(pushAppService.findAllPushApplicationsForDeveloper(extractUsername(request))).build();
> >>>>   }
> >>>>
> >>>>
> >>>> If the option 2 is the correct. How the Angular.js service would look
> >>>> like? Once the username is not informed as argument on
> >>>> pushApplicationService.js, because for obvious reasons it can be
> >>>> retrieved with HttpServletRequest.
> >>>>
> >>>> One of my poor ideas due to my "amazing" Angular skills would be to do
> >>>> something like:
> >>>>
> >>>>   @GET
> >>>>   @Produces(MediaType.APPLICATION_JSON)
> >>>>   @RolesAllowed("admin")
> >>>>   @Path("/all")
> >>>>   public Response listAllPushApplications(){
> >>>>     //queries
> >>>>   }
> >>>>
> >>>> And:
> >>>>
> >>>> backendMod.factory('pushApplication', function ($resource) {
> >>>> return $resource('rest/applications/all/:verb', {
> >>>> .....
> >>>>
> >>>>
> >>>> Help?
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>>
> >>>> abstractj
> >>>> PGP: 0x84DC9914
> >>>> _______________________________________________
> >>>> aerogear-dev mailing list
> >>>> aerogear-dev at lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>>
> >>> _______________________________________________
> >>> aerogear-dev mailing list
> >>> aerogear-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>
> >>
> >>
> >> --
> >> Matthias Wessendorf
> >>
> >> blog: http://matthiaswessendorf.wordpress.com/
> >> sessions: http://www.slideshare.net/mwessendorf
> >> twitter: http://twitter.com/mwessendorf
> >
> >> _______________________________________________
> >> aerogear-dev mailing list
> >> aerogear-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
> >
> > --
> >
> > abstractj
> > PGP: 0x84DC9914
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev

--

abstractj
PGP: 0x84DC9914