add USE_DEMO_PATIENT env variable toggle and safe session handlers

[louisthaboogie]

No description provided.

[louisthaboogie]

/gemini review

[gemini-code-assist]

Code Review

This pull request introduces a USE_DEMO_PATIENT environment variable to toggle between a hardcoded demo patient and the authenticated user's identity. Feedback identifies a potential SQL injection vulnerability and logic redundancy in agent.py, suggesting that the agent should rely on the session's user ID. Additionally, it is recommended to explicitly handle missing session emails in app.py to prevent unintended fallbacks to the demo account.

[gemini-code-assist]

This block introduces two concerns:

1. Redundancy: The USE_DEMO_PATIENT check is already performed in the application layer (app.py), which sets the session's user_id accordingly. The agent should ideally be agnostic of this configuration and rely solely on callback_context.session.user_id to identify the patient.
2. Security: Constructing the SQL query with f-string interpolation poses a SQL injection risk. Even if the input is expected to be an email address from a trusted session, it is best practice to use parameterized queries if the tool supports them, or ensure the input is properly sanitized.

    patient_key = callback_context.session.user_id
    query = f"SELECT profile FROM patients WHERE _key='{patient_key}'"

References

1. Avoid hardcoding user identifiers in database queries; use dynamic values from the session or callback context instead.

[gemini-code-assist]

When USE_DEMO_PATIENT is set to false, falling back to the demo email (john.doe@gmail.com) if the session email is missing might be confusing and lead to unexpected behavior. It is safer to handle the missing email case explicitly to ensure the agent uses the correct user identity.

Suggested change

	user_email = session.get('email', "john.doe@gmail.com")
	user_email = session.get('email')
	if not user_email:
	return jsonify({"error": "User email not found in session"}), 400

[gemini-code-assist]

Code Review

This pull request introduces a 'Demo Mode' configuration via the USE_DEMO_PATIENT environment variable, allowing the health concierge agent to toggle between a hardcoded demo patient and the authenticated user's email. Documentation and example environment files have been updated to reflect this change. However, a high-severity security vulnerability was identified in backend/agent.py, where the SQL query is constructed using an f-string with a user identifier, making it susceptible to SQL injection.

[gemini-code-assist]

Constructing SQL queries using f-strings with user identifiers like patient_key is a security risk (SQL injection). Furthermore, avoid hardcoding or manually passing user identifiers in queries. Instead, use dynamic values from the session or callback context (e.g., callback_context.session.user_id) to ensure the application functions correctly and securely for different users.

References

1. Avoid hardcoding user identifiers, such as email addresses, in database queries. Instead, use dynamic values from the session or callback context (e.g., callback_context.session.user_id) to ensure the application functions correctly for different users.

[louisthaboogie]

/gemini review

[gemini-code-assist]

Code Review

This pull request introduces a demo mode configuration for the Bigtable AI Health Concierge agent, allowing users to toggle between a hardcoded demo patient and the authenticated user's email via the USE_DEMO_PATIENT environment variable. Key changes include updating the documentation, environment examples, and modifying the backend logic in agent.py and app.py to support dynamic user identification and SQL query escaping. I have no feedback to provide as there were no review comments.