Technical foundation

Datagate's security system is built on Microsoft ASP.NET Core Identity — a mature framework widely used in enterprise applications. Security is not an added layer on top of the application, but an integral part of the architecture, with mechanisms that work at the database level.

Login

Each user logs in with their own credentials (username and password). Sessions are managed through secure, time-limited tokens.

Structural protection

All internal IDs of records are encrypted before being exposed in URLs or parameters. This makes browser addresses opaque — a user can't guess or manipulate a document's ID by changing the URL.

Protection covers two common types of attacks: SQL injection (attempting to manipulate the database through modified parameters) and brute-force (sequentially traversing numbers to guess document IDs).

Roles

A role groups a set of permissions that correspond to a real function in the organization: warehouse operator, cashier, salesperson, store manager, administrator. The role defines what the user sees and can do in the system.

Each user is assigned to one or more roles. A store manager, for example, can have both the role of manager and cashier, if operations require it. Administration is done centrally — a role change is immediately applied to all users who have assigned it.

Permissions

Permissions work at the page level, with two access modes: view (the user sees the data, but can't change it) and edit (the user sees and can edit).

Permissions are not managed at the field or section level in the document. This decision is deliberate and serves three purposes:

• Performance — checking rights on every element on the page would consume significant resources, both on the server and in the browser
• Simplicity in administration — field-by-field combinations would be impossible to manage correctly at scale and would generate dangerous loopholes
• Predictability — a user either has access to a page or not; no grey areas

This approach ties directly into the interface philosophy: if a warehouse operator doesn't need to see prices, they simply don't have access to the pricing page — they don't need field-level restrictions.

Application separation

Datagate allows for complete separation of applications that share the same data. For example, a company may have an SFA app for salespeople and a B2B app for direct customer access.

Master data is common between applications — items, customers, prices, barcodes. It doesn't duplicate or sync; They are the same data, accessed from different applications.

Business logic, security, and users are completely separate. Each application has its own users, its own security groups, and its own resource consumption. A configuration error in SFA does not accidentally allow access to data from B2B. This separation is essential in scenarios where end customers have access to the system — a B2B customer should not be able to see, under any circumstances, another customer's data or internal company information.