POST
|
I've been troubleshooting an issue with OAuth token refresh issues in our app that started around the time we updated to 100.6. The issue is manifesting as users needing to re-login every app launch. Our app is using the OAuthAuthorizationCode grant type so we can retrieve a refresh token. It appears that the runtime is making an "exchange_refresh_token" request instead of a standard "refresh_token" request when an access token has expired. We haven't seen this behaviour prior to 100.6. We have been caching the refresh token so our users would not need to login on every app restart, but with this change to "exchange_refresh_token" we no longer have a valid refresh token cached if the user is using an app longer then 30 minutes (access token length). I cannot discover a way to detect when the refresh token is change. The credentials object does have a PropertyChanged event, but this is not invoked when the refresh token changes, only when the access token changes. This is a major breaking change for our app and I'd like to understand why the runtime is making an "exchange_token_refresh" request. Was this introduced in 100.6? If it was, was it to solve a specific issue or improve security? Would someone be able to point me in the direction of how to detect when the refresh token is updated by the runtime?
... View more
11-15-2019
03:41 PM
|
0
|
2
|
4116
|
POST
|
I am unable to get you the exact request that fails or a code snippet at this time as I am currently working on another project but I can tell you it is the very first request DownloadPreplannedOfflineMap makes once started (a /data endpoint if I recall correctly). We have a challenge handler set but it doesn't get called at all when this happens. The request/download task simply fails with a 498 HttpRequestException. We get the 498 after we start DownloadPreplannedOfflineMap. By the time we get to this point, other code has already run that is using security successfully. But if the download is started after the token expires (if the app was sitting open for a while) we get the 498. If we do pretty much anything else, like re-create the preplanned map area object before we download, that will successfully refresh the token. Sometimes the refresh happens transparently by the runtime, sometimes it uses our configured challenge handler (we haven't figured out what the determining factor is that chooses which to use) and the download will occur successfully if tried after.
... View more
02-13-2019
03:30 PM
|
0
|
0
|
469
|
POST
|
We've encountered a few scenarios where the runtime (100.4) doesn't try to refresh an expired token for secured resources. The most recent one we've worked around is DownloadPreplannedOfflineMap from the DownloadPreplannedOfflineMapJob. It seems that the download doesn't try to refresh an expired token if the call returns a 498 status code. Shortened stacktrace (removed our callstack): System.Net.Http.HttpRequestException: Response status code does not indicate success: 498 (). at System.Net.Http.HttpResponseMessage.EnsureSuccessStatusCode() at Esri.ArcGISRuntime.Internal.RequestRequiredHandler.<IssueRequestAndRespond>d__14.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) We've seen this exception occur in other offline scenarios but have since added other calls through the runtime that have alleviated the issue. I have seen that the runtime does react to a 401 status code and the 498 is put in the response content, whereas in this issue's case the status code returned is 498. Is there any way to get the runtime to react appropriately to the 498 when it is returned as a status code so that it will try to refresh the token? I'd like to be able to write a fix that encompasses the whole project rather than having to test every call to see if it will or will not refresh tokens.
... View more
01-31-2019
03:16 PM
|
0
|
2
|
552
|
POST
|
Runtime version: 100.4 (issues were present in 100.3 as well) Sometimes when using an app, the MapView control will lock up visually when the app is restored from a suspended state (minimized, lock screen, etc...) in Windows (UWP). This is an intermittent issue that we have been able to reproduce with a simple Xamarin.Forms app that only has a MapView with a loaded webmap. This is difficult to reproduce with a debugger attached so the easiest way to reproduce is to work with an app without a debugger. Steps: 1) Minimize the app 2) Maximize the app 3) Very quickly minimize the app again while the map is re-rendering Intermittently, the map control will look like it has locked up, but the rest of the application will still be functional. This is easy to see if you use a tiled basemap as some of the tiles will not render in on restore. You can sometimes get the map working again by doing another minimize/maximize. While the map is locked up it is, in fact, still working as trying to pan the map then getting it to unlock using minimize/maximize will show that the map has panned. Click events are also still handled but the map coordinates correspond to where the map may have been panned to, not what is visually displayed. This is a concerning issue for us as we have encountered this when people simply leave their computers locked. When they come back they find they can't use the map. Minimize/maximize doesn't always restore the visual map functionality. We also can't expect our users to know that if the map locks up to do this. We're worried that this could occur when our users are halfway through completing a task and be unable to proceed, which would mean they have to close/re-open and start over. Has anyone encountered issues with the map locking up on UWP? We're looking for some guidance in trying to resolve this issue.
... View more
12-13-2018
03:54 PM
|
0
|
2
|
689
|
Online Status |
Offline
|
Date Last Visited |
04-08-2021
11:42 AM
|