st.runtime.get_instance()._session_mgr.list_active_sessions()[0].client.request.protocol is http on https pages.

[wyattscarpenter]

Checklist

• I have searched the existing issues for similar issues.
• I added a very descriptive title to this issue.
• I have provided sufficient information below to help reproduce this issue.

Summary

st.runtime.get_instance()._session_mgr.list_active_sessions()[0].client.request.protocol is http on https pages.

Reproducible Code Example

import streamlit as st

st.write( st.runtime.get_instance()._session_mgr.list_active_sessions()[0].client.request.protocol )

# When run from an https source, like *.streamlit.app, this will still list http.

Steps To Reproduce

No response

Expected Behavior

Should be https

Current Behavior

Is http

Is this a regression?

• Yes, this used to work in a previous version.

Debug info

• Streamlit version: Streamlit, version 1.33.0
  And also whatever streamlit community cloud uses.

Additional Information

No response

[github-actions]

If this issue affects you, please react with a 👍 (thumbs up emoji) to the initial post.

Your feedback helps us prioritize which bugs to investigate and address first.

[kajarenc]

Hey @wyattscarpenter and thank you for opening this issue!

Could you please describe your use case why you need to use protocol in your streamlit app?

This probably a issue on interaction with Cloud / Streamlit Open source library, since Streamlit apps there deployed under reverse proxy, so most probably corresponding headers doesn't pass to Streamlit app itself.

[wyattscarpenter]

Simply put, I want my app to use the URL on which it is deployed for various purposes (such as displaying to the end user and for implementing Google sign-in), and the protocol is part of that url.

…

On Mon, May 6, 2024, 2:25 PM Karen Javadyan ***@***.***> wrote: Hey @wyattscarpenter <https://github.com/wyattscarpenter> and thank you for opening this issue! Could you please describe your use case why you need to use protocol in your streamlit app? This probably a issue on interaction with Cloud / Streamlit Open source library, since Streamlit apps there deployed under reverse proxy, so most probably corresponding headers doesn't pass to Streamlit app itself. — Reply to this email directly, view it on GitHub <#8600 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGQZNEA5CWA5HA3NEEZIQELZA7DKHAVCNFSM6AAAAABHEZD6VOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOJWGY2TAMJXGY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[vdonato]

Hi @wyattscarpenter,

I'm not sure if there's much we can do about this in the Streamlit OS lib side. The issue is most likely because, in a Community Cloud deployment, the connection is indeed an http connection since the TLS connection isn't terminated by the Streamlit server, it's terminated at the load balancer level (and security is maintained by having the network permissions set such that the Streamlit server only accepts traffic from the load balancer in front of it).

This would be true of any deployment made where the Streamlit server itself isn't configured to terminate the TLS connection, and while we do have some basic configurability for this included in our config options (see the server.sslCertFile and server.sslKeyFile), it's unlikely we'll add full support for this in Community Cloud given the community focus of the product.

[wyattscarpenter]

Interesting!

Well, fixing this isn't crucial for me, so feel free to deprioritize it, etc.