02. Anmeldung und Berechtigungen

Zwei unterschiedliche Anmeldungen

API-Benutzer: Der technische HTTP-Zugriff wird im geprüften Servercode mit einem X-ERP-Benutzer und einem Sitzungscookie authentifiziert.

Geschäftspartner im Portal: Partner/ValidateCredentials prüft anschließend fachliche Portal-Zugangsdaten. PartnerToken verwaltet wiedererkennbare Portal-Sitzungen. Diese Funktionen ersetzen die technische HTTP-Anmeldung nicht.

Technischer Cookie-Login

POST /api/WebApiUser/WebApiLogin erwartet im JSON-Body email, password und databaseName. Optional sind rememberMe, keepLoggedIn und keepLoggedInHours. Der geprüfte Code verwendet das Cookie X-ERPAppAuthCookie mit Secure, HttpOnly und SameSite=Lax. Verwenden Sie einen HTTP-Client mit Cookie-Verwaltung und HTTPS; bauen Sie keinen Bearer-Header aus einem PartnerToken-Hash.

Der Firmendatenbankname wird bei erfolgreicher Anmeldung als DatabaseName in den Anmeldekontext übernommen. Führen Sie für unterschiedliche Firmen getrennte Cookie-Sitzungen. Eine Änderung der PartnerId wechselt nicht die Firma.

Im geprüften LoginHelper setzt der API-Login ohne keepLoggedIn zunächst 20 Minuten Ablaufzeit mit möglicher Verlängerung durch die Cookie-Konfiguration. Mit keepLoggedIn begrenzt der Helper die angeforderte Dauer auf maximal 168 Stunden. Das Eingabemodell nennt zwar bis zu 720 Stunden, der Helper begrenzt enger. Verlassen Sie sich auf das tatsächliche Sitzungsverhalten Ihrer Serverversion und behandeln Sie Ablauf kontrolliert.

Ist ein Passwortwechsel vorgeschrieben, muss das Konto vor dem unbeaufsichtigten Einsatz entsprechend eingerichtet sein. Fehlgeschlagene Anmeldungen können Kontosperren auslösen; keine unbeschränkten Login-Wiederholungen. Der Login besitzt außerdem eine Ratenbegrenzung.

Berechtigungen nach Aktion

Die HTTP-Methode allein bestimmt das Recht nicht. Maßgeblich ist der Autorisierungsfilter der Aktion. Im geprüften Code gelten unter anderem:

• Artikelkatalog und Artikeldetails: Webshop-Read.
• Partner/ValidateCredentials: Partner-Read, obwohl die HTTP-Methode POST ist.
• PartnerToken/CreateSession: PartnerToken-Create.
• PartnerToken/ValidateSession und GetActiveSessions: PartnerToken-Read.
• PartnerToken/RevokeSession und RevokeAllSessions: PartnerToken-Delete, obwohl die Methode POST ist.
• Warenkorb und Kundeninformationen lesen: WebshopUserCart-Read.
• AddToCart, WebshopPlaceOrder, GiveRating und ClearCart: WebshopUserCart-Create. Insbesondere ClearCart verwendet im geprüften Code kein Delete-Recht.
• UpdateCartItem: WebshopUserCart-Update.

Für Helpdesk-Abfragen und -Änderungen stimmen Sie die benötigten controllerbezogenen Read-/Update-Rechte mit dem Betreiber ab. Nur die tatsächlich benötigten Rechte vergeben; Schreibrechte einzeln freigeben.

Kundenzuordnung und Browser-Anwendungen

Eine übergebene PartnerId ist ein Parameter, kein Nachweis einer Zugriffsberechtigung. Die Zuordnung zwischen angemeldetem Benutzer, Firma und erlaubten Geschäftspartnern muss projektbezogen geprüft werden. Testen Sie auch den abgewiesenen Zugriff auf fremde Partnerdaten.

Halten Sie technische Zugangsdaten auf einem vertrauenswürdigen Server. Für browserübergreifende beziehungsweise fremde Origins müssen Cookie-, CORS- und CSRF-Konzept ausdrücklich abgestimmt sein. SameSite=Lax bedeutet nicht, dass beliebige Cross-Site-Aufrufe mit Cookie funktionieren.

Grenze der Aussage

Diese Beschreibung basiert auf dem lokalen Servercode vom 18.09.2026. Sie ist kein Testnachweis für die aktuell installierte Kundenumgebung. Basisadresse, Kontotyp, freigegebene Firmen und Anmeldeweg müssen vor dem ersten produktiven Zugriff bestätigt werden.