Challenge Handler not called in WPF

[JoeHershman]

Hi,

Am seeing some really odd behavior with Windows and authentication.  I have code that works fine in Xamarin forms on iOS.  Very simple, just setting up Authentication.  What I am seeing though is that in WPF (both Win standard and NET6) the challenge handler does not get called.  It just does not go into the method, and then I get an unauthorized error trying to open the item.  As I said, the same code works in Xamarin Forms, I can look at the AuthenticationManager and see a registered method for the challenge handler, but it does not enter the method.

Any thoughts on something additional needed in WPF.  I have gone through the samples and do not see anything being done that differs

Thanks - Joe

[MatveiStefarov]

Hello!  I am investigating this issue and trying to narrow down possible causes.  I have a couple questions for you.

Does your WPF application have a global APIKey (i.e. ArcGISRuntimeEnvironment.ApiKey property is set to some non-empty value)?  How about the Xamarin apps?

Have you tried generating a token ahead of time, using AuthenticationManager.Current.GenerateCredentialAsync(...) followed by AuthenticationManager.Current.AddCredential(...)?  This is a possible workaround for challenge-detection issues, if you know the server/username/password combination ahead of time.

[JoeHershman]

The desktop apps do have a API key set, because this was just going to be online.  The Xamarin is setup for offline.

Also, I am trying to do this using OAth not just user/password.  However, I have tried the approach you mention.  I will get the OAuth to popup, it seems I have a credential in there when looking at AuthenticationManager in debugger, but I get a token error

[MatveiStefarov · Accepted solution]

Alright, thank your for this extra information!  I think I know what's going on.

Setting a global APIKey is meant to be an alternative to making users log into the app.  It is one of three ways to add an access token to app's network requests.  Mixing multiple token sources in one application can lead to problems.  What I think is happening in your case is -- having the API key set means that every request to arcgis.com already has an access token, which interferes with credential-challenge detection and can even prevent a TokenCredential from being used.

If your app will always require users to log in, then you probably don't need to use that API key.  See if removing the APIKey allows the ChallengeHandler and/or TokenCredential to work.

But if your app needs to have logging in optional -- e.g. by switching from API key to named-used authentication mid-flight -- that will be tricky.  That's not really a scenario we've tested so far, and I'd be curious to learn more about your use case.

[JoeHershman]

I'll give a try when I get the chance.  I will say, imo, that defeats the point of being able to use an API key for public layers.  An application that has a workflow of the user only needing a basemap without private operational layers is certainly realistic, and it would be nice if in these cases they didn't have to log on.  So the log-on would only pop up when they need to add an operational layer.

I'll let you know after I test

Thanks - Joe

[MatveiStefarov]

A couple more ideas:

• Instead of setting the global APIKey on ArcGISEnvironment, which affects access to everything on arcgis.com, you could try setting the APIKey properties on individual resources.  You could set a key on individual Basemaps, Layers, Tasks, or ServiceFeatureTables). Setting a key on one resource does not interfere with TokenCredentials for other resources.
• Try resetting the global ApiKey property when there is a need to log into a protected resource.  I realize that this can be a tricky situation to detect when ChallengeHandler does not get called.  I'll investigate if we can detect the APIKey-TokenCredential clash in our networking code and at least provide more helpful error messages / make workarounds simpler.

[JoeHershman]

That did work.  Removed the setting of the APIKey at the initialization stage and then when trying to add the feature layer it works.

Right now have just ran a quick test but this should move me forward

Thanks - Joe