nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

IdentityManager gets bad tokens

BrianRassier

We're using IdentityManager to access secure ArcGIS Online services. About 50% of the time this works as expected:
a) We access the service
b) A "499 Token Required" response is obtained
c) IdentityManager triggers a token request
d) The token is appended on the original request
e) Service access is granted

However, the other 50% of the time we get a series of "403 You do not have permissions to use this resource" errors. These happen in response to step d) above. Then a new token is requested, and we continue looping through this process until we successfully get to the service.

Occasinally it takes 2-4 token requests before we finally get access to the service. The troublesome part is, sometimes we seem to get in a loop that never ends. We've seen 20-30 failed requests before we kill our app. This has happened a few times today alone.

Anyone seen this? Any insight into why it's happening?

Vind meer berichten getagd met

Runtime SDK for WPF

Accepted answers

DominiqueBroux

Without setting the referrer, there are always 2 token requests when obtaining a token. The first fails saying Referrer must be specified. Then IdentityManager must recognize that and it adds Client=requestip, which gets the token.

That's normal. If there is no default referer, we first try to generate a token without any option i.e a short lived token. But arcgis.com doesn't support short lived token yet. So we catch the error and try to generate a token for the current IP.

However, it does fail 25-50% of the time on that second request too.

Interesting. I never observed this case. Might be due to your firewall config and an arcgis.Com change I never noticed.
Anyway, it's a good practice to use a referer with OnPremise and OnLine portals in order to avoid issues.

With the referrer set, we only get 1 token request, because the first request has client=referrer and referrer=arcgis.com in the request. I tried 20+ times and I never got the failure I've been seeing, so this seems very promising.

Great 🙂

What is the recommended value for referrer since this isn't a web-based application we're using? I didn't get a solid feel for that based on the API documentation.

With the WPF API (unlike Silverlight and WinPhone API) you can use the referrer you want (e.g your application name).
Once a token has been generated for a specific referer, the Identity Manager will automatically add the referrer as header of the requests that need the token (you should be able to observe that with fiddler).

Hope this helps.

All comments

BrianRassier

Thanks again for this insight. Things are looking good with these adjustments so far.

DominiqueBroux

Without setting the referrer, there are always 2 token requests when obtaining a token. The first fails saying Referrer must be specified. Then IdentityManager must recognize that and it adds Client=requestip, which gets the token.

However, it does fail 25-50% of the time on that second request too.

With the referrer set, we only get 1 token request, because the first request has client=referrer and referrer=arcgis.com in the request. I tried 20+ times and I never got the failure I've been seeing, so this seems very promising.

Great 🙂

What is the recommended value for referrer since this isn't a web-based application we're using? I didn't get a solid feel for that based on the API documentation.

BrianRassier

Thanks for your reply. We are setting the challenge method to progammatically generate the token. So the token requests should be identical every time, and not for a different user.

I did try to set the referrer like you mention. I saw some interesting results. Without setting the referrer, there are always 2 token requests when obtaining a token. The first fails saying Referrer must be specified. Then IdentityManager must recognize that and it adds Client=requestip, which gets the token. However, it does fail 25-50% of the time on that second request too.

With the referrer set, we only get 1 token request, because the first request has client=referrer and referrer=arcgis.com in the request. I tried 20+ times and I never got the failure I've been seeing, so this seems very promising.

I will do some more testing, but this seems to be a good work-around. One last question - What is the recommended value for referrer since this isn't a web-based application we're using? I didn't get a solid feel for that based on the API documentation.

DominiqueBroux

What kind of Challenge method did you set? Is it a challenge method that generates a token progammatically or is there an UI?

From your description, it looks as if a token was generated automatically by the challenge method but for a wrong user.
In this case, the IM gets in a loop to give a chance to the user or to the program behind the challenge method to log in with the right user.
However the loop is limited to 20 tentatives then the request fails (as if the user cancelled the sign in dialog).

Note: if not already done, we can try to set a referer for the token generation. Something like IdentityManager.Current.TokenGenerationReferer = "arcgis.com". Though, that should not explain the error you reported.

Doe mee aan het gesprek

Aangemelde leden kunnen berichten plaatsen, updates volgen en meer. Nieuw hier? Registreer een gratis account.

Snelle Links

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.