15

The online docs mention(requires login) that the access_token JSON returned by a call to the access_token.svc returns something like:

{"access_token":"HufXeuUt%2FYYElA8SYjJOkUkrXxV9dyXRirmKhjW%2Fb%2FU%3D","expires_in":300}

However when we've tried this we get this:

{"access_token":"client_id%3dtestuser%26expiresOn%3d1361873823640%26digest%3dIaiLIug%2bRRYeEszC5syFvlHod9qXWUi0fx4aZFiaS2c%3d","expires_in":300}

The right-hand string decodes as:

client_id=testuser
&expiresOn=1361873823640
&digest=IaiLIug+RRYeEszC5syFvlHod9qXWUi0fx4aZFiaS2c=

When we try and pass this to the subsequent OData call we end up with an exception:

System.IO.IOException: Unable to read data from the transport connection: The connection was closed.

Should we be extracting something out of the encoded string, the "digest" bit perhaps? If so the documentation needs updating!

EDIT

Our logs are showing:

2013-02-26 12:52:46,700 ERROR OAuth2AccessToken - Digest is wrong

No idea why?

Also, we updated the Datasources.xml to enable OAuth and provide the client id/secret - the CM still able to successfully connect and display comments!

It seems that the access token is working correctly for the CM but not in our code.

  • Have you tried passing the digest as the token? Both are Base64-encoded strings, which look to be hashes of some kind, so it sounds like it's worth a shot. – Ant P Feb 26 '13 at 22:18
  • Yep - didn't work. We've had some traction if we decode the access_token first after receiving item, then add it as a header. We now get a 403 - different error, but the UGC integration with the CM has no problems so we're still al little confused. – Neil Feb 27 '13 at 8:54
9

Like you mentioned, the protocol is this:

  1. You make a post request to the access token end-point to get a token (you need to provide here your client_id and your client_secret as headers or as query parameters);

  2. You get an answer similar to this: {"access_token":"sometoken","expires_in":300}; 2.1 Worth knowing is that the token is url encoded and in UTF-8 format so, on Java side you need to do URLDecoder.decode("sometoken", "UTF-8"); while on .NET side you need to do HttpUtility.UrlDecode("sometoken", System.Text.Encoding.UTF8);;

  3. Your next request needs to include the authorization header. On Java side you do builder.header("authorization", "OAuth " + decodedTokenString); while on .NET side you can use Client.Headers["authorization"] = "OAuth " + DecodedTokenString;

Worth mentioning is that the SharedSecret defined in the cd_webservice_conf.xml (/Configuration/AuthenticationServer/SharedSecret/) of the TokenAccessPoint needs to be the same as the SharedSecret defined in the cd_ambient_conf.xml (/Configuration/Security/SharedSecret/) of the (WebService)EndPoint.

Are you sure you decoded properly the token gotten from the server? Are you sure that you configured the proper SharedSecret in the two configuration files?

Hope this helps.

  • Thank you Daniel. The problem appeared to be not decoding the token before we used it. – Neil Feb 28 '13 at 8:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.