Proposal: Add "Manage Active Sessions" to User Preferences

[itisAliRH]

📋Description

I’d like to propose adding a "Manage Active Sessions" feature under User Preferences in Galaxy.

💬 Background:

I briefly discussed this idea with @bgruening, and we also tested the existing "Sign Out All" functionality in the EU instance. During this test, we noticed that it revoked all sessions except one ⚠️, which might be a potential bug. This observation further highlights the need for more granular session management.

Additionally, many modern platforms (e.g., Google, GitHub, Dropbox) offer similar functionality, allowing users to view and manage their active sessions for enhanced security and control. Implementing this feature would align Galaxy with these best practices.

🔎 Current Situation

Currently, Galaxy provides a "Sign Out All" button in the Settings section, which revokes access to all active sessions for a user. This action operates on the galaxy_sessions table, which stores key session-related information such as: create_time, remote_host, remote_addr, is_valid and last_action. While helpful, this approach lacks granularity. Users may want more control over their active sessions without having to sign out from all devices.

When a user clicks "Sign Out All", the corresponding session rows are deleted from the galaxy_sessions table. While this effectively terminates the sessions, it raises a question:
❓Should we delete the session records, or should we mark them as inactive (e.g., by setting is_valid = false)?

• Deleting sessions removes historical data, limiting the ability to audit session activity.
• Marking sessions as inactive preserves session history, which can be valuable for security audits and troubleshooting.

💡Proposed Feature

Add a "Manage Active Sessions" section where users can:

1. View all active sessions linked to their account, displaying details like:

   • Login timestamp (create_time)
   • Last activity (last_action)
   • IP address (remote_addr)
   • Device/Browser info (if feasible)

2. Revoke individual sessions selectively instead of signing out from all devices.

3. Session State Handling: Consider changing session revocation behaviour to mark sessions as inactive rather than deleting them, preserving session history.

✅ Benefits

• Enhanced Security: Users can spot suspicious sessions and revoke them individually.
• Better Control: Users don’t need to disrupt all sessions when only one needs termination.
• Transparency: Visibility into active sessions improves user trust.
• Auditability: Retaining inactive session records can help with security audits and troubleshooting.
• Alignment with Standards: This feature would bring Galaxy in line with the session management capabilities offered by many widely-used platforms.

⚙️ Technical Considerations

• Leverage data from the existing galaxy_sessions table.
• Possibly enhance session metadata to capture additional info (like device/browser details).
• Evaluate whether to delete sessions upon revocation or mark them as inactive (is_valid = false).
• Ensure that revoking individual sessions updates the session status appropriately.

❓ Open Questions

1. Are there any potential security concerns or performance implications with exposing session metadata to users?
2. Should we add device/browser fingerprinting for clearer identification of sessions?
3. Could the "Sign Out All" behaviour we observed (failing to revoke one session) indicate an existing bug that needs addressing?
4. Should session revocation delete the session record or simply mark it as inactive for better auditability?

Looking forward to hearing thoughts, feedback, and suggestions from the community! 🙌

[jdavcs]

Should session revocation delete the session record or simply mark it as inactive for better auditability?

We can simply invalidate them by setting is_valid to false - that's what we currently do, right? Let's not delete them though: we have a batch deletion mechanism in #19872. More importantly, that would enable a user to intentionally delete their previous sessions (see related discussion on committers channel on 3/26/25).