-
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
[EBT] userId
hash: Find alternatives to js-sha256
#130147
Comments
Pinging @elastic/kibana-core (Team:Core) |
Loading a browser hashing library for this is not worth it IMO. But what I feel needs addressing more is where this logic lives; I believe the ID creation belongs on the server side more than doing it ad-hoc on the browser. If we were to add a cookie with this ID passed from the server when serving a page, where would be the best place to attach this cookie header? the service is already in core so I think it should be relatively easy to plug in. |
Correct me if I'm wrong, but this userId is coming from the cloud plugin's config. Core has no knowledge of such data. And there's no way atm to let plugins register additional headers/cookie to bind to the rendering service, so it wouldn't be possible to do that from the cloud plugin either atm. So this approach can't be achieved without proper enhancement. I don't see it in the issue's description, so if I may ask: what's the problem with the current implementation / what exactly are we trying to solve or improve here? |
@pgayvallet AFAIK, the main benefit would be removing the dependency, hence the size of the bundle. It is loaded async, but still... |
I agree the main benefit would be removing an extra dependency that might expose us to vulnerabilities if we decide to maintain it and avoid loading an additional library to do only this tiny task on the browser. It also helps in centralizing the logic of where we create this ID |
I noticed core exposes a |
We can use the browser native digest function here:
https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypto/digest
Though it only works on https which might be an OK tradeoff?
Alternatively, wouldn't t be better to send a request to a custom route on the kibana server to get this in a GET/POST request instead of loading an external library?
Originally posted by @Bamieh in #129927 (comment)
The text was updated successfully, but these errors were encountered: