function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
tjn11tjn11 

Error Using access_token obtained via refresh token flow

I am using the refresh token flow to obtain an access token to use in REST API calls. Im succesfully getting an access token back in the response from my refresh token flow call. The problem is that performing a simple query like "select name from user" with the RESP API and the access token returned from the refresh token flow gives me the following error.

 

The remote server returned an error: (500) Internal Server Error.

An unexpected error occurred. Please include this ErrorId if you contact support: 2141401881-27724 (-1063440253)

errorCode:UNKNOWN_EXCEPTION

 

I can get an access token using the username-password flow and make the same query no problem.

 

In either case, im putting the following in the header of query call

 

"Authorization: OAuth " + AccessToken

 

do I need to put something different when my access token was obtained via a refresh token flow?

 

 

Vinita_SFDCVinita_SFDC

Hello,

 

In the header please provide Authorization: Bearer + Access token in the header. For details plesase refer following link which explains with example:

 

http://wiki.developerforce.com/page/Digging_Deeper_into_OAuth_2.0_on_Force.com

tjn11tjn11
Thanks for the reply!

I changed what I'm adding to the header for subsequent REST API calls from

"Authorization: OAuth " + access_token

to

"Authorization: Bearer " + access_token

with no luck. Still getting the Internal Server Error.

After reading more last night about OAuth, I'm not sure if what we are
trying to do is even supported. Here is what we are trying to do. Can you
confirm if this should be possible?

1) During the installation of our managed package, our canvas app captures
a refresh token.
2) We store that refresh token in a database (not salesforce)
3) Now that we have a refresh token, we have some background processes that
are trying to use this refresh token to obtain an access token. This part
is working, we are getting an access token. The issue is when we try to
make a subsequent REST API call with that access token.

So, the question is, can multiple apps from different locations use the
same refresh token or is the refresh token only valid for the original app
that captured it with the web-server flow?

-tjn11
Vinita_SFDCVinita_SFDC

Hello,

 

As messaged I have serched app server logs and can see error stating: java.lang.IllegalArgumentException: key longer than max=200. Please investigate your code and check if it is hitting some sort of limit.

 

Thanks!

Puneet _MishraPuneet _Mishra

did you resolve this issue, i am also trying to sync my salesforce to Google calendar but don't know to get access token which last long or have life span more that 1 hour,  if you ever solve this issue then please tell me how can i achieve this

Thanks in advance

tjn11tjn11
salesforce is still working on this issue for us. However, for our
situation we discovered that the refresh token returned from the web server
flow is significantly different depending on what the "immediate" parameter
is set to. When the "immediate" parameter is set to true, the refresh token
is much longer vs when the "immediate" parameter is set to false. I'm not
saying that's the case for everyone, it's just our experience.

When setting the "immediate" parameter to "true", which is what we we're
doing at first, we we're getting the internal server error later on when
using the access token returned from the refresh-token flow when providing
the refresh token we obtained from the web-server flow with the "immediate"
parameter set to "true".

When we set the "immediate" parameter to "false" for our web-server flow,
our issue that occurs later on with the access token went away. In our case
we didn't need to have the "immediate" parameter set to "true". So, we're
good right now. Still interested to see what sf comes back with regarding
our issue.

Hope this helps!