-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
User Sessions shared across multiple users behind Proxy or VPN #1407
Comments
Hey @dvdr00t! I'm here to help you with any bugs, questions, or contributions you have for Chainlit. Let's squash those bugs together! To ensure that each user has a unique session in a Chainlit application, even when multiple users access it from the same IP address through a proxy or VPN, you can rely on the Here's how you can achieve this:
Here's a code snippet demonstrating this approach: user_sessions: Dict[str, Dict] = {}
class UserSession:
def get(self, key, default=None):
if not context.session:
return default
if context.session.id not in user_sessions:
user_sessions[context.session.id] = {}
user_session = user_sessions[context.session.id]
return user_session.get(key, default)
def set(self, key, value):
if not context.session:
return None
if context.session.id not in user_sessions:
user_sessions[context.session.id] = {}
user_session = user_sessions[context.session.id]
user_session[key] = value Additionally, implementing authentication mechanisms such as password authentication, OAuth, or custom header authentication can enhance security and ensure unique user identification. By defining a |
#1442 is probably related. |
This improves Socket.IO configuration and CORS handling for cross-origin use cases, particularly focusing on scenarios where Chainlit is embedded in other websites (copilot, closes #1279) or deployed behind load balancers: - Make Socket.IO client transports configurable via `project.transports` setting - Move connection parameters from headers to Socket.IO auth object for better websocket compatibility - Update CORS handling to properly support authenticated cross-origin requests. Closes #1359. - Remove unnecessary task start/end events from window_message handler BREAKING CHANGE: For cross-origin deployments, wildcard "*" is no longer supported in allow_origins when using authenticated connections. Specific origins must be listed in the project config. Possibly resolves #719, #1339, #1369, #1407, #1492, #1507.
Should be resolved with #1575. Would love feedback as to whether indeed the issue is resolved! |
This improves Socket.IO configuration and CORS handling for cross-origin use cases, particularly focusing on scenarios where Chainlit is embedded in other websites (copilot, closes Chainlit#1279) or deployed behind load balancers: - Make Socket.IO client transports configurable via `project.transports` setting - Move connection parameters from headers to Socket.IO auth object for better websocket compatibility - Update CORS handling to properly support authenticated cross-origin requests. Closes Chainlit#1359. - Remove unnecessary task start/end events from window_message handler BREAKING CHANGE: For cross-origin deployments, wildcard "*" is no longer supported in allow_origins when using authenticated connections. Specific origins must be listed in the project config. Possibly resolves Chainlit#719, Chainlit#1339, Chainlit#1369, Chainlit#1407, Chainlit#1492, Chainlit#1507.
Describe the bug
When multiple users access the Chainlit application from the same IP (e.g., when behind a proxy or VPN), the
user_session
is shared across those users, leading to data from one session being accessible by another. This results in a mixing of session data, causing unexpected behavior, such as retrieving or storing incorrect session-specific information.To Reproduce
Steps to reproduce the behavior:
cl.user_session.set()
andcl.user_session.get()
.Expected behavior
Each user should have a unique session, even when accessing the application from the same IP address, ensuring that session-specific data remains private to each user.
Screenshots
If applicable, add screenshots to help explain the problem.
Desktop (please complete the following information):
Smartphone (please complete the following information):
Additional context
The issue seems to stem from how user sessions are identified and stored. In the current setup, it appears that sessions are identified solely by the session ID, which may not be properly isolated for different users behind the same IP. As a result, users sharing the same IP (e.g., through a corporate proxy or VPN) can end up sharing the same session, causing a mix-up of session data.
The text was updated successfully, but these errors were encountered: