-
Notifications
You must be signed in to change notification settings - Fork 8.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Handle access tokens that expire after authentication stage. #122155
Handle access tokens that expire after authentication stage. #122155
Conversation
306ab6d
to
b84d178
Compare
f9c8b6d
to
7b31989
Compare
7b31989
to
3cd3617
Compare
Pinging @elastic/kibana-security (Team:Security) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have just a couple of nits, really scraping the bottom of the barrel here.
Nice job!
|
||
const existingSessionValue = await this.getSessionValue(request); | ||
if (!existingSessionValue) { | ||
this.logger.warn('It is not possible to extend session since it is no longer available.'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand that a successful re-authentication always attempts to extend the session. However, if I was reading through the logs, I think I would find the log messages a bit confusing:
WARN: Re-authenticating request due to error: blah
WARN: It is not possible to extend session since it is no longer available.
Perhaps we could reword this to make it a bit clearer what's happening. WDYT about this?
this.logger.warn('It is not possible to extend session since it is no longer available.'); | |
this.logger.warn('Session is no longer available and cannot be re-authenticated.'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps we could reword this to make it a bit clearer what's happening. WDYT about this?
Yeah, sounds better, thanks
// We can ignore `undefined` value here since it's ruled out on the previous step, if provider isn't | ||
// available then `getSessionValue` should have returned `null`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 I appreciate the comment here
return toolkit.notHandled(); | ||
} | ||
|
||
this.logger.warn(`Re-authenticating request due to error: ${getDetailedErrorMessage(error)}`); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We're seeing this behavior pretty regularly for some users, and AFAIK there's nothing "wrong" with their configuration. So maybe this should be a debug
log level instead of warn
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, that's good point - it was useful during development, but can be quite confusing in production.
expect(reauthenticate).not.toHaveBeenCalled(); | ||
}); | ||
|
||
it('does not handle error when security is disabled in elasticsearch.', async () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Question: this is just defensive coding, we don't really ever expect a 401 error if security is disabled in ES, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Correct, just covering if
code branches in the hook, but we shouldn't get 401 here. Unless security was disabled when request reached Kibana, then application handler was busy with something, in the meantime ES enabled security, and only then application handler decided to query Elasticsearch and obviously got 401
- 0.00001% chance 🙈
💚 Build Succeeded
Metrics [docs]
History
To update your PR or re-run it, just comment with: |
💔 All backports failed
How to fixRe-run the backport manually:
Questions ?Please refer to the Backport tool documentation |
Summary
In this PR we introduce a new
Authenticator.reauthenticate
method that is invoked in a Core'ssetUnauthorizedErrorHandler
handler to refresh user's access token if it's expired after authentication stage.Fixes: #104893
Release note: Previously long-running requests could lead to sporadic logouts in certain cases even though user's session was still active. It shouldn't be the case now.