[Feat]: Per-user and tenant-scoped database access in Tabularis Web

Start by reading src-tauri/src/transport/web/auth.rs, src-tauri/src/application/api.rs, src-tauri/src/application/connections.rs, and src-tauri/src/transport/web/rpc_connection_policy.rs to trace identity, authorization, and connection access. Then trace other connection consumers and session-owned resources before defining the isolation boundary. Done means the acceptance criteria hold across direct RPCs, stored workspace data, caches, events, and revocation, with adversarial cross-tenant integration tests and standalone behavior preserved when disabled.

Prerequisites

• I have written a descriptive issue title
• I have searched existing issues to ensure the feature has not already been requested

🚀 Feature Proposal

Add opt-in, server-enforced access control so a shared Tabularis Web deployment can give authenticated users access only to their assigned database connections.

External platforms should remain responsible for identity and customer membership. Tabularis should consume a trusted identity and enforce the corresponding access grants.

Current behavior on main

Verified against commit bbeec182:

• Proxy authentication already exists. authenticate_proxy in src-tauri/src/transport/web/auth.rs validates the shared secret and supplied user string, but does not retain that identity in the issued session. This is authentication at the deployment boundary, not per-user connection authorization.
• ApplicationRequestContext carries a session ID and authorization level, but no external user or tenant principal. Connection listing loads the instance-wide catalogue without filtering it by external identity.
• Web RPCs already enforce authorization levels and connection security restrictions, and connection responses redact secrets. Extend these protections rather than treating the backend as having no authorization today.
• Direct connection navigation already exists at /connections/:connectionId/editor. A URL must remain only a navigation target, never an access grant. Password login currently redirects to / and loses the requested destination; preserving that destination is separate from tenant isolation and belongs to #1275.

The feature should support:

• Binding each session to a verified user and tenant.
• Administrator-managed grants linking users or teams to specific connections and permitted database targets.
• Filtering connection lists and enforcing the same permissions on every backend operation.
• Isolating saved queries, history, notebooks, cached metadata, and connection-related events between tenants.
• Revoking access for existing sessions.
• Associating audit events with the authenticated user, tenant, and connection without exposing credentials or query results.

Database read/write privileges should remain enforced by appropriately restricted database accounts. UI restrictions or SQL classification alone must not be treated as a read-only guarantee.

Acceptance criteria

• A user cannot list, open, query, modify, or obtain metadata for an unassigned connection, including through direct RPC requests or guessed identifiers.
• Database-selection overrides cannot escape the connection’s authorized targets.
• Identity and tenant context come from the trusted authentication integration, never from unverified browser parameters.
• Existing cookies cannot bypass identity binding or updated access grants.
• Connection pools, caches, events, and stored workspace content cannot expose another tenant’s data.
• Revocation blocks subsequent operations and closes affected event streams. Handling of running queries and transactions is documented, including cancellation limitations.
• Integration tests cover two tenants, users with different grants, direct API bypass attempts, identity changes, and revocation.
• Existing standalone behavior is preserved when this feature is disabled.

This complements managed connections (#1273), provisioning (#1274), and connection links (#1275). Billing, container orchestration, and database provisioning are outside this issue’s scope.

Motivation

SaaS platforms and hosting panels need to offer database access to multiple customers without exposing other customers’ connections or workspace content.

Proxy authentication currently gates entry to a deployment without retaining an external principal for connection authorization. A shared deployment needs identity binding, access grants, and isolation of user data in addition to that existing authentication boundary.

Separate instances for groups with identical permissions remain a deployment alternative. Managed connections (#1273) and a provisioning API (#1274) do not, by themselves, make a shared instance safe for users with different access rights.

Example

An external platform provisions connections for Customer A and Customer B. Alice belongs to Customer A and can access its assigned database. Bob belongs to Customer B and can access a different database.

Neither user can discover or use the other customer’s connection, including through manually crafted requests. Removing Alice’s grant blocks further database access even if her Tabularis session is still valid.

Where to start

• src-tauri/src/transport/web/auth.rs: trusted identity validation and session identity binding.
• src-tauri/src/application/api.rs: propagate the authorization principal in ApplicationRequestContext.
• src-tauri/src/application/connections.rs: catalogue access and connection operations that need grant enforcement.
• src-tauri/src/transport/web/rpc_connection_policy.rs: existing transport restrictions to preserve and complement.
• Trace all other connection consumers and session-owned resources before defining the isolation boundary. A filtered connection list alone is not sufficient.

Contributor notes

• Follow the repo rules in .rules/ (Rust, TypeScript, React, design tokens, accessibility, testing).
• Add any new UI strings to every locale under packages/web-ui/src/i18n/locales/.
• Keep shared authorization logic in src-tauri/src/application/ and Web authentication and endpoints in src-tauri/src/transport/web/; preserve the desktop-free build.
• Run the relevant tests and repository checks, including cargo check --no-default-features from src-tauri/ for backend changes. Include adversarial cross-user and cross-tenant authorization tests.
• Questions? Ask here or on Discord.