02. Authentication and permissions
Clearly distinguish between technical authentication, business partner sessions, company context and rights.
Two separate authentication steps
API users: Technical HTTP access is authenticated in the audited server code with an X-ERP user and a session cookie.
Business partners in the portal: Partner/ValidateCredentials then checks technical portal access data. PartnerToken manages recognizable portal sessions. These functions do not replace the technical HTTP login.
Technical cookie login
POST /api/WebApiUser/WebApiLogin expects email, password and databaseName in the JSON body. The fields rememberMe, keepLoggedIn and keepLoggedInHours are optional. The checked code uses the cookie X-ERPAppAuthCookie with Secure, HttpOnly and SameSite=Lax. Use an HTTP client with cookie management and HTTPS; do not build a Bearer header from a PartnerToken hash.
If the logon is successful, the company database name is adopted as DatabaseName in the logon context. Maintain separate cookie sessions for different companies. Changing the partner ID does not change the company.
In the tested LoginHelper, the API login without keepLoggedIn initially sets an expiration time of 20 minutes with a possible extension through the cookie configuration. With keepLoggedIn, the helper limits the requested duration to a maximum of 168 hours. Although the input model states up to 720 hours, the helper limits it more narrowly. Rely on the actual session behavior of your server version and handle expiration in a controlled manner.
If a password change is required, the account must be set up accordingly before unsupervised use. Failed logins can trigger account suspensions; no unlimited login repeats. The login also has a rate limit.
Permissions by action
The HTTP method alone does not determine the required permission. The authorization filter of the action is decisive. The following applies in the checked code:
- Item catalog and item details:
Webshop-Read. - Partner/ValidateCredentials:
Partner-Read, even though the HTTP method is POST. - PartnerToken/CreateSession:
PartnerToken-Create. - PartnerToken/ValidateSession and GetActiveSessions:
PartnerToken-Read. - PartnerToken/RevokeSession and RevokeAllSessions:
PartnerToken-Delete, even though the method is POST. - Read shopping cart and customer information:
WebshopUserCart-Read. - AddToCart, WebshopPlaceOrder, GiveRating and ClearCart:
WebshopUserCart-Create. In particular, ClearCart does not use delete rights in the tested code. - UpdateCartItem:
WebshopUserCart-Update.
For helpdesk queries and changes, agree on the required controller-related read/update rights with the operator. Only assign the rights that are actually required; Release write permissions individually.
Customer mapping and browser applications
A passed PartnerId is a parameter, not proof of access authorization. The assignment between logged in user, company and permitted business partners must be checked on a project-by-project basis. Also test denied access to third-party partner data.
Keep technical credentials on a trusted server. For cross-browser or foreign origins, the cookie, CORS and CSRF concepts must be expressly coordinated. SameSite=Lax does not mean that any cross-site calls with cookies will work.
Limit of statement
This description is based on local server code as of 09/18/2026. It is not proof of testing for the currently installed customer environment. The base address, account type, approved companies and login method must be confirmed before the first production request.