Details
-
Bug
-
Status: Closed
-
Blocker
-
Resolution: Fixed
-
None
-
None
Description
There's an intermittent failure in JWT authentication, with a roughly 20% failure rate (depends on the network latency). Upon investigating, I identified a race condition due to simultaneous HTTP requests within the authentication process. Here's the chain of events:
- The user initiates the OAuth/IdProvider authentication process. Once completed, they are redirected back to Solr.
- LoginController is then activated to handle the response from the IdProvider.
- LoginController calls "resetMenu" method which triggers requests to the "admin/info/system" and "admin/cores" endpoints. These requests are bound to fail as the auth.header hasn't been set yet.
- The authentication process continues with the processing of the IdProvider's response. If successful, the auth.header is set.
- The response from step 3 is received and returns a 401 error, causing the auth.header to be unset in app.js.
- This results in the session being terminated and the entire authentication process failing.
This race condition, where requests are made before setting the authentication header and their subsequent failure clears an already set header, leads to the observed intermittent authentication issues.
Is the "resetMenu" call necessary ? My inclination is that this is useless because why would you need to reset the menu in the middle of an authentication process? All we need is either show or hide the menu depending on the existence or not of an active user session. The menu would be reset after the user is authenticated.
Replaced the call to resetMenu with a call to a newly added method showHideMenu and it worked nicely.
$scope.showHideMenu = function() {
$scope.http401 = sessionStorage.getItem("http401");
};
Attachments
Issue Links
- links to
