[
https://issues.apache.org/jira/browse/SOLR-16991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl reassigned SOLR-16991:
----------------------------------
Assignee: Jan Høydahl
> 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
> Assignee: Jan Høydahl
> Priority: Blocker
> Time Spent: 1h
> Remaining Estimate: 0h
>
> 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]
