New Streamlit Release: 0.54.0

Version 0.54.0

Highlights:

  • :keyboard: Support for password fields! Just pass type="password" to
    st.text_input().

Notable fixes:

  • :eight_spoked_asterisk: Numerous st.cache improvements, including better support for complex objects.
  • :speaking_head: Fixed cross-talk in sidebar between multiple users.

Breaking changes:

  • If you’re using the SessionState hack Gist, you should re-download it!
    Depending on which hack you’re using, here are some links to save you some
    time:
11 Likes

If anyone’s up for sharing, I’d be curious to hear how folks are planning to use the password fields.

Are you authenticating with some service external to your Streamlit app?

Or authenticating with your Streamlit app itself (so you’ve got users and password hashes stored somewhere, and don’t show the user your content until they authenticate…)? Any thoughts about security specific to using Streamlit that way?

Following up on David’s question for anyone having users log in: how are you planning to keep track of who is logged in for a given session between reloads?

I could imagine using the session state gists… or leaving the password encoded in the page at each reload. But if anyone has a better approach, I’d love to hear it.

1 Like

I capture a user name with a text box, and save in a SessionState attribute on startup. Having a valid name disables the prompt on reruns.

As it is an internal site and inside our firewall the password isn’t essential - eventually we’ll want a single sign mechanism either in Streamlit or through some proxy/rerouting.

At some point we may control who can see what content through the user name, but that’s another lookup table for Department/Role and something we’d want to retrieve through LDAP[S] or something similar.

1 Like