You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@usergrid.apache.org by "Michael Russo (JIRA)" <ji...@apache.org> on 2016/07/29 20:41:20 UTC

[jira] [Updated] (USERGRID-1304) HTTP 500 error when retrieving Entity via connection

     [ https://issues.apache.org/jira/browse/USERGRID-1304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Russo updated USERGRID-1304:
------------------------------------
    Sprint: Usergrid 36

> HTTP 500 error when retrieving Entity via connection
> ----------------------------------------------------
>
>                 Key: USERGRID-1304
>                 URL: https://issues.apache.org/jira/browse/USERGRID-1304
>             Project: Usergrid
>          Issue Type: Bug
>          Components: Stack
>    Affects Versions: 2.1.0
>            Reporter: David Johnson
>
> From the Usergrid mailing list:
> I've noticed that the errors Usergrid returns seem somewhat
> inconsistent. For example, when attempting to GET an entity that doesn't
> exist directly from the collection (omitting org and app from path for
> clarity):
> GET /things/ferrari
> will return an error "entity_not_found", but attempting to GET the same
> entity through a connection where I "own" the entity:
> GET /users/me/owns/things/ferrari
> will return an "uncaught" error, with error_description "Internal Server
> Error."
> Is this intentional? I was expecting to get an "entity_not_found" error
> in both cases, as I think this would be a pretty common situation to
> have in a system where entities are created and deleted dynamically.
> (If /things/ferrari actually exists and I own it, both queries return it
> as expected, so that's cool.)
> If I've understood the design intent behind Usergrid correctly, these
> connections are extremely important because I can map permissions to
> them. Therefore it's not always possible to access objects directly
> under the collection, as the user may only have permission to access
> objects through a connection (e.g. "owns"). I like this scheme a lot,
> it's simple, intuitive, yet powerful.
> Here are curl commands that reproduce the behavior:
> curl -X POST "http://localhost/udwc/brikoleur/token" -d '{ "grant_type"
> …
> : "password",  "username" : "abogdanov", "password" : "thepassword" }'
> {"access_token":"YWMtpgdKYDbyEeaD2zHg-adLzwAAAVWSPvYGkxL-sP9RrdRTbAGgQJijcOXcApE","expires_in":604800,"user":{"uuid":"2349d142-317a-11e6-9322-080027cf389a","type":"user","name":"Alexander
> Bogdanov","created":1465831132919,"modified":1465841524921,"username":"abogdanov","email":"psulonen@gmail.com","activated":true,"picture":"http://www.gravatar.com/avatar/fd1ebc06694e703c1b0c64215890a865","metadata":{"size":608},"repeatPassword":"thepassword"}}
> …
> curl --header "Authorization: Bearer
> YWMtpgdKYDbyEeaD2zHg-adLzwAAAVWSPvYGkxL-sP9RrdRTbAGgQJijcOXcApE"
> "http://localhost/udwc/brikoleur/users/abogdanov/owns/things/ferrari"
> {"error":"uncaught","timestamp":1466432732273,"duration":0,"error_description":"Internal
> Server
> Error","exception":"org.apache.usergrid.rest.exceptions.UncaughtException","error_id":"d87217ed-36f2-11e6-b273-080027cf389a"}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)