[aerogear-dev] Admin endpoints

[Sébastien Blanc]

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