[aerogear-dev] Admin endpoints
Sébastien Blanc
scm.blanc at gmail.com
Thu Oct 9 16:54:41 EDT 2014
Envoyé de mon iPhone
> Le 9 oct. 2014 à 22:48, Bruno Oliveira <bruno at abstractj.org> a écrit :
>
> Tested locally here, it's pretty much possible to check the roles
> programatically with
> http://docs.oracle.com/javaee/6/api/javax/ws/rs/core/SecurityContext.html#isUserInRole(java.lang.String)
>
> I'm just not sure about adding IF's all along the code.
Seems we have replied almost synchronously :) . See my previous message , let's see what is the best option and I would love to hear more opinions about this .
>
>> On 2014-10-09, Bruno Oliveira wrote:
>>> 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.
>>
>>>
>>>
>>> -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
>
> --
>
> abstractj
> PGP: 0x84DC9914
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
More information about the aerogear-dev
mailing list