-
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
ExecutionContext: encode all context fields when converting to header #125783
ExecutionContext: encode all context fields when converting to header #125783
Conversation
515e421
to
8a27a19
Compare
@@ -50,18 +50,23 @@ export interface IExecutionContextContainer { | |||
} | |||
|
|||
function stringify(ctx: KibanaExecutionContext): string { | |||
const stringifiedCtx = `${ctx.type}:${ctx.name}:${encodeURIComponent(ctx.id!)}`; | |||
const stringifiedCtx = `${encodeURIComponent(ctx.type)}:${encodeURIComponent( |
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.
It's not strictly necessary to encode type
and name
since Kibana controls their value. We can even add a runtime validation. OTOH, it doesn't hurt and adds some extra safety.
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.
since Kibana controls their value
Can't any arbitrary consumer just call core.executionContext.withContext({...someContext, name: '☺☺☺'}, () => { ... })
? At least on the server-side?
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.
You can. That's why I mentioned a runtime validation. But as said, let's keep it as additional protection.
Pinging @elastic/kibana-core (Team:Core) |
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.
VisEditors changes LGTM
…elastic#125783) * ExecutionContext: encode all context fields when converting to header value * switch back to using the vis type name instead of title for the execution context name * adapt FTR tests * fix server-side tests too (cherry picked from commit d047765)
…elastic#125783) * ExecutionContext: encode all context fields when converting to header value * switch back to using the vis type name instead of title for the execution context name * adapt FTR tests * fix server-side tests too (cherry picked from commit d047765)
💚 All backports created successfully
Note: Successful backport PRs will be merged automatically after passing CI. Questions ?Please refer to the Backport tool documentation |
…#125783) (#125924) * ExecutionContext: encode all context fields when converting to header value * switch back to using the vis type name instead of title for the execution context name * adapt FTR tests * fix server-side tests too (cherry picked from commit d047765) Co-authored-by: Pierre Gayvallet <pierre.gayvallet@elastic.co>
…#125783) (#125925) * ExecutionContext: encode all context fields when converting to header value * switch back to using the vis type name instead of title for the execution context name * adapt FTR tests * fix server-side tests too (cherry picked from commit d047765) Co-authored-by: Pierre Gayvallet <pierre.gayvallet@elastic.co>
Summary
Fix #125700
x-opaque-id
valuename
of the vis when creating context instead oftitle
Checklist