[
https://issues.apache.org/jira/browse/SOLR-16991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lamine updated SOLR-16991:
--------------------------
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|https://github.com/apache/solr/blob/51c1a785c4611d0103f7b73c8adefa028d608bcd/solr/webapp/web/js/angular/controllers/login.js#L21]";
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|https://github.com/apache/solr/blob/51c1a785c4611d0103f7b73c8adefa028d608bcd/solr/webapp/web/js/angular/controllers/login.js#L151].
# The response from step 3 is received and returns a 401 error, causing the
_auth.header_ to be
[unset|https://github.com/apache/solr/blob/51c1a785c4611d0103f7b73c8adefa028d608bcd/solr/webapp/web/js/angular/app.js#L440]
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.
{code:java}
$scope.showHideMenu = function() {
$scope.http401 = sessionStorage.getItem("http401");
};
{code}
was:
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|https://github.com/apache/solr/blob/51c1a785c4611d0103f7b73c8adefa028d608bcd/solr/webapp/web/js/angular/controllers/login.js#L21]";
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|https://github.com/apache/solr/blob/51c1a785c4611d0103f7b73c8adefa028d608bcd/solr/webapp/web/js/angular/controllers/login.js#L151].
# The response from step 3 is received and returns a 401 error, causing the
_auth.header_ to be
[unset|https://github.com/apache/solr/blob/51c1a785c4611d0103f7b73c8adefa028d608bcd/solr/webapp/web/js/angular/app.js#L440]
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.
{quote}$scope.showHideMenu=function() {
$scope.http401=sessionStorage.getItem("http401");
};{quote}
> Concurrent requests failing JWT Auth intermittently
> ---------------------------------------------------
>
> Key: SOLR-16991
> URL: https://issues.apache.org/jira/browse/SOLR-16991
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Authentication
> Reporter: Lamine
> Priority: Blocker
>
> 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|https://github.com/apache/solr/blob/51c1a785c4611d0103f7b73c8adefa028d608bcd/solr/webapp/web/js/angular/controllers/login.js#L21]";
> 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|https://github.com/apache/solr/blob/51c1a785c4611d0103f7b73c8adefa028d608bcd/solr/webapp/web/js/angular/controllers/login.js#L151].
> # The response from step 3 is received and returns a 401 error, causing the
> _auth.header_ to be
> [unset|https://github.com/apache/solr/blob/51c1a785c4611d0103f7b73c8adefa028d608bcd/solr/webapp/web/js/angular/app.js#L440]
> 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.
>
> {code:java}
> $scope.showHideMenu = function() {
> $scope.http401 = sessionStorage.getItem("http401");
> };
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
