Once a back office serves more than one role, the important question is not only who can sign in. It is what each person can see and change afterwards. A ParitLAB manager handles customers and licences within a portfolio assigned by an administrator. That role should not expose unrelated projects or customers owned by another manager.
Access has two dimensions
We separate product scope from customer ownership. Product scope defines which projects a manager can license. Ownership defines which customer records appear in the portal. Product access alone cannot reveal every customer, and owning a customer does not permit a licence for a project outside the assigned portfolio.
Hidden navigation is not security
Navigation communicates scope, but a user can still alter a URL or construct an HTTP request. Customer creation, editing, licence grants and revocation therefore recheck the manager ID, customer owner and project assignment on the server. The conditions are included in the SQL that reads or updates the record so a missing interface check does not become an access bypass.
Manager sessions remain separate
A similar interface does not justify a shared session. Manager state is separate from administrator and client state, and the session ID changes after login. A suspended account or mismatched session version loses access when the next request validates the account.
Administrators control product-level permissions
The manager editor assigns projects, customers, trial access and download access per product. New permission fields start disabled so a deployment cannot expose files to an existing account by accident. A product appears in the manager portfolio only when at least one trial or download permission is enabled.
Checks we perform
- Owned customers appear while unrelated customers are absent from the response.
- Projects outside the portfolio are missing from licence controls.
- A forged project ID creates no licence.
- A forged customer edit changes no record.
- An unauthenticated request returns to the manager login page.
A reusable rule
A useful permission model can be explained in one sentence: “This manager owns these customers and handles these products.” Every query and action should be able to prove that sentence. Ownership-based queries allow the system to grow from one manager to many without separate databases and make audit records more useful than a simple log of button clicks.