I’m using streamlit to build some internal dashboards, and one of the processes I’ve got in there is caching some database calls, so that every time a user interacts with the dashboards, we don’t need to re-pull our source data. However, when investigating a caching error, I noticed that the error logs were fairly verbose and appeared to expose our DB credentials (error message sampled below) when printing the hash chain. Does anyone have any ideas/answers on potentially reducing the verbosity level of this error message or on a way forward that doesn’t expose sensitive creds?
While caching the body of `pl_base_data_component()`, Streamlit encountered an
object of type `builtins.weakref`, which it does not know how to hash.
If you don't know where the object of type `builtins.weakref` is coming
from, try looking at the hash chain below for an object that you do recognize,
then pass that to `hash_funcs` instead:
Object of type builtins.list: [(..., (<class 'sqlalchemy.pool.impl.QueuePool'>, ...),... {'client_flag': 2, 'host': <DB_HOST>, 'passwd': <DB_PASSWORD>, 'user': <DB_USERNAME>}]]
My actual credentials are pulled from environment vars; only a reference to the host name is included in the actual script. The function which I’m caching here executes a sql query, so it includes the sqlalchemy db connection object.
you can hide error messages within the app through a config variable. Just create a file .streamlit/config.toml in your project dir with the following content:
[client]
showErrorDetails = False
We recommend doing that for secure production apps and we also enable that by default on Streamlit’s Community Cloud. More info on config options here. We try to keep exception messages as helpful as possible, that’s why we are showing the detailed information to you during development.
Let me know if that works for you or if you have any other concerns.
Actually @jrieke a follow up - reading through the configs documentation, it appears that the errors would still print in their entirety to the console. If we’re logging the stdout/console (because they’re on a deployed container), then the DB creds exposed in the error message would still be logged, would they not? Of course, its still an improvement over the creds being shown in the browser, but some concerns might still remain.
Hey @_Senth_N, yes the error would still print to the command line. This is something we are thinking about changing, so feel free to add your thoughts to the discussion here
Got it - done. Would really hope to see this implemented, as it is a roadblock for the time being to have an exception that ends up exposing credentials to our logs.
Thanks for stopping by! We use cookies to help us understand how you interact with our website.
By clicking “Accept all”, you consent to our use of cookies. For more information, please see our privacy policy.
Cookie settings
Strictly necessary cookies
These cookies are necessary for the website to function and cannot be switched off. They are usually only set in response to actions made by you which amount to a request for services, such as setting your privacy preferences, logging in or filling in forms.
Performance cookies
These cookies allow us to count visits and traffic sources so we can measure and improve the performance of our site. They help us understand how visitors move around the site and which pages are most frequently visited.
Functional cookies
These cookies are used to record your choices and settings, maintain your preferences over time and recognize you when you return to our website. These cookies help us to personalize our content for you and remember your preferences.
Targeting cookies
These cookies may be deployed to our site by our advertising partners to build a profile of your interest and provide you with content that is relevant to you, including showing you relevant ads on other websites.