-
Notifications
You must be signed in to change notification settings - Fork 546
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
Passing Bearer token when connecting to remote workspace #1152
Comments
Hi We are using "evidently-secret" header in order to protect write api. You should never use this functionality for authorization. But, of course, you can have your own proxy authorization layer just before running "evidently ui" (i think modifying evidently source code is bad idea for your purposes). This layer just check token, if ok - proxy request to running "evidently ui" server Is it helpful for you? |
Thanks for the reply @DimaAmega, perhaps the Documentation on this could be clarified a little bit. Right now it simply states: It is a bit ambiguous and I initially assumed this was basically the auth token required to access the remote server. MLFlow has done something similar (see https://mlflow.org/docs/latest/auth/index.html#using-environment-variables). I understand this is unfortunately not possible with Evidently. We can work around it and secure the service in a different way, but more clarity in the documentation would be appreciated. |
I am trying to setup a self hosted ML monitoring with Evidently.
I have Evidently running inside a container on a remote host. The host requires an Authorization header with a Bearer token.
According to the documentation, passing a secret is possible via:
However, it looks like Evidently passes the secret value as
evidently-secret
header instead of anAuthorization
header. (see here and here)Would it be possible to allow users to specify the name of the header the secret should be attached to?
The text was updated successfully, but these errors were encountered: