apigee “Subject does not have permission” to get l

问题:

Code that was previously working to get the logged in user is now failing. For the default role I have a few permissions including this one (in the list at /roles/xxx/permissions):

"get:/users/me"

To verify I didn't break something in the API, I logged in from Curl (names modified to protect the guilty):

curl -X POST "https://api.usergrid.com/xxx/xxx/token" -d '{"grant_type":"password", "username":"test", "password":"xxx"}'

This gets a valid response with an access token:

{"access_token":"YWMxxxNnAHCEeSEEUF6k0-adAAAAUcaO_3R5IcK1ftFnDt0x52NVSoHEATWD6Q","expires_in":604800,"user":{"uuid":"a2517xxx-d3dc-11e3-b4fb-17caf255a670","type":"user","name":"Test User","created":1399243032076,"modified":1399243032076,"username":"test","email":"[e-mail]","activated":true,"picture":"http://www.gravatar.com/avatar/b64xxx217b34b1e8d3bd915fc65c4452"}}

Using this access token, compose the Curl request to get /users/me:

curl -X GET https://api.usergrid.com/xxx/xxx/users/me?access_token=YWMxxxNnAHCEeSEEUF6k0-adAAAAUcaO_3R5IcK1ftFnDt0x52NVSoHEATWD6Q

Now instead of working as I believe it used to, I get this:

{"error":"unauthorized","timestamp":1404289792782,"duration":0,"exception":"org.apache.shiro.authz.UnauthorizedException","error_description":"Subject does not have permission [applications:get:d5e9e5a0-d310-11e3-a524-df009e0fbc2f:/users/a25174ca-d3dc-11e3-b4fb-17caf255a670]"}

Have I broken something and just missing it? I tried deleting the permission and recreating it but that didn't help either. Thanks!

回答1:

To my knowledge, you cannot use 'me' as the entity to retrieve self. You would need to specify the actually username or uuid of the user entity. Luckily when you retrieve a token, that info is passed back in the response, so you can save it.

See getting a user in the Apigee docs.

回答2:

@remus question prompted me to find an example on the security page to show where I had gotten the permission from. However, the page http://apigee.com/docs/app-services/content/managing-access-defining-permission-rules now shows this example:

GET,PUT,POST,DELETE:/users/me/**

I'm fairly certain that wasn't the case earlier as this code had been working for weeks with the prior permission. Maybe I bumped my head :-) hopefully anyone else having this problem will find this. The curl examples posted in the question now work fine with this permission set (although I only added GET permission in my case).