Hi.
Using arcgis server webadaptor 10.7
Windows authentication is configured as instructed in documantations.
When first accessing a secured service from web application, a windows login dialog is displayed (expected behavior) :
* the netowrk request while windows dialog invoked
Once credentials are entered, user is authorized and is able to access the service (as expected):
*The validated reponse headers after credentilas are validated
* The validated request haeders after credentilas are validated
The problem is when we close the browser (chrome Version 99.0.4844.51) and reopen it, trying to access the same service results with a 401 error in the network, and cors error in the console log:
The expected results should be -
Either the server remebers valid credentials and authorize accsess service, or invoke login dialog.
The currnet behvior is none of the above. The only way to invoke Windows login dialog is by hard-reload the browser (dev-tools must be open for that), or directly load the requested service in another browser tab and re-enter credentials in the Windows login dialog that is invoked there.
Please help. Are we missing something? Is this a known issue?
Solved! Go to Solution.
For future generations:
We managed to overcome this issue.
Apperantly, we had a service worker in our app which cahced the request above with invalid credentials.
Our problem was solved by unregistrating that Service worker.
When first accessing a secured service from web application, a windows login dialog is displayed (expected behavior)
In my experience, this isn't the expected behavior. The only way I could trigger this would be in an incognito window from Chrome or edge.
But my experience is based on:
With that in place, the users are authenticated automatically based on a Kerberos Ticket and don't have to enter their username and password when they access a resource via the webadapter. This works well with Edge, Chrome and of course IE, Firefox might need some additional settings to get this working.
Are you using AD as well in your case?
Hi.
I am using Active Directory.
I would expect an SSO behavior as you described, but we can accept login dialog behavior for initial use.
A more serious problem for us is the inconsistent behavior forcing the user to perform hard reload or access the service's URL directly
For future generations:
We managed to overcome this issue.
Apperantly, we had a service worker in our app which cahced the request above with invalid credentials.
Our problem was solved by unregistrating that Service worker.