Per-restaurant session isolation
Avoid a generic login that lets someone infer the existence of other restaurants, and ensure every session is resolved within its own tenant.
Last updated: 2026-09-18 · Owner: Flexora engineering team
Alternatives considered
- Discarded
- Keep a shared generic login.
- Chosen
- Resolve access and sessions per restaurant.
Decision made
Establish per-restaurant access, identified by its own tenant identifier, and redirect generic access to the corresponding login.
Rationale
Closes the documented cross-tenant enumeration vector and aligns login with restaurant-level isolation.
Frequently asked questions
- What did Pyae decide about "per-restaurant session isolation"?
- Establish per-restaurant access, identified by its own tenant identifier, and redirect generic access to the corresponding login.
- How is data isolated between restaurants in a multi-tenant SaaS?
- In Pyae, login and session are always resolved within the tenant that corresponds to each restaurant. A generic login gets redirected to that specific tenant's login, instead of exposing a shared entry point across restaurants.
- What is a cross-tenant enumeration vector?
- It's when a shared generic login lets someone infer, even indirectly, that other restaurants or tenants exist in the system. Pyae closes that vector by resolving access per restaurant starting at login.
- Is a shared generic login safe across restaurants?
- No, because it can leak information about the existence of other tenants to users who have no permission to see it. That's why Pyae resolves login and session per restaurant, identified by its own tenant.
Does your multi-client system need this same level of isolation?
Closing cross-tenant enumeration vectors is part of building custom software that's secure by design, not an afterthought.