[
https://issues.apache.org/jira/browse/USERGRID-1319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15571307#comment-15571307
]
Jaskaran commented on USERGRID-1319:
------------------------------------
[~mrusso] - we are not seeing any error logs (Usergrid) when this issue occurs.
In fact we see normal logs (nothing too different or out of the ordinary).
That said, we've tried to isolate the issue further, and observed Usergrid
RESPONSE (in this error scenario) is different from the RESPONSE when we
provide an incorrect client_id/client_secret i.e. clearly the error appears to
be different from a simple case of wrong credentials (client_id/client_secret).
See the two cases/scenario documented below:
*CASE 1: Intentionally set an incorrect client_id/client_secret in the request*
{code}
HTTP 401 Unauthorized
{
"error": "invalid_client",
"timestamp": 1476338071956,
"duration": 0,
"error_description": "Unable to authenticate (OAuth)",
"exception": "org.apache.usergrid.rest.exceptions.SecurityException"
}
{code}
*CASE 2 (ERROR scenario): Set correct client_id/client_secret in the request*
{code}
HTTP 401 Unauthorized
{
"error": "unauthorized",
"timestamp": 1475131455582,
"duration": 0,
"error_description": "Subject does not have permission to access this
resource",
"exception": "org.apache.usergrid.rest.exceptions.SecurityException"
}
{code}
As mentioned earlier, the ERROR scenario (CASE 2) is random in nature, but with
a difference. When it shows up, it consistently stays that way (i.e. all
subsequent requests in a particular "org" using client_id/client_secret fail)
for many hours, sometimes even for days. And then, for no obvious reason the
ERROR stop comings (for an org). At any point of time, for the same usergrid
installation, we have some orgs where the ERROR is showing up (consistently)
and other orgs which are working fine. And this situation can change (after
some hours) and an org that was working starts showing the ERROR and possibly
vica-versa.
Hope this helps. Happy to provide any additional details or execute any
additional tests that may help identify the issue? Do let me know.
> client_id & client_secret Errors (2.2.0)
> ----------------------------------------
>
> Key: USERGRID-1319
> URL: https://issues.apache.org/jira/browse/USERGRID-1319
> Project: Usergrid
> Issue Type: Bug
> Components: Stack
> Affects Versions: 2.2.0
> Environment: OS: Ubuntu 14.04;
> Cassandra version: 2.2.6 (DataStax);
> Elasticsearch version: 1.4.4;
> Tomcat version: 7;
> JDK version: 1.8.0_65 (Oracle);
> Usergrid version: 2.2.0 (Master branch, 2nd Sep, SHA:
> 9fae8037a4b881e9c13a5a1f23f71dc34e950c40)
> Reporter: Jaskaran
> Fix For: 2.2.0
>
>
> We are migrating our application from 1.0.2 to 2.2.0 (Master branch, 2nd
> September, SHA: 9fae8037a4b881e9c13a5a1f23f71dc34e950c40). We have observed a
> new issue (in 2.2.0, Master branch), while using valid client_id &
> client_secret. Below is a sample request and response.
> Request:
> http://<server>/<org>/<app>/users?client_id=<client_id>&client_secret=<client_secret>
> Response:
> Http 401 Unauthorized
> {
> "error": "unauthorized",
> "timestamp": 1475131455582,
> "duration": 0,
> "error_description": "Subject does not have permission to access this
> resource",
> "exception": "org.apache.usergrid.rest.exceptions.SecurityException"
> }
> Notes on the Error and Observations:
> (1) The unauthorised error (with client_id and client_secret) is random (but
> quite frequent) - ‘suddenly’ all Usergrid API calls fail.
> (2) On its own, after some times (few hours), the same call with same
> client_id and client_secret will start working again.
> (3) The problem is NOT related to Loading of the system. It occurs during
> NO-LOAD conditions as well.
> (4) We have tested and ‘not’ observed this issue (with client_id and
> client_secret) with 2.1.0 and 1.0.2 releases.
> (5) Interestingly, the user access tokens (access_token) ‘always’ works with
> 2.2.0 - it is the current workaround we’re using.
> Note, since admin token expires in 7 days - we can not continue using this
> workaround approach (user access_token).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
