# Änderungen in Ihrem System
Überblick
Nachdem Sie die migrierten Login-Clients in DocCheck Access geprüft haben, passen und testen Sie die Implementierung in Ihrem eigenen System.
# Testumgebung
Erstellen Sie eine Testumgebung, bevor Sie die bestehende Implementierung ersetzen.
Verwenden Sie die Daten aus DocCheck Access:
- Login-Button-HTML
- Login-Button-Script-Tag
- Login-Client-ID
- Login-Client-Secret
Diese Werte können Sie im Button-Konfigurator über Daten teilen sammeln und weitergeben.
# Login-Client-Implementierung austauschen
Ersetzen Sie die bisherige Implementierung durch den neuen Login-Button und Script-Code aus DocCheck Access.
Auch wenn im alten System bereits ein DocCheck Login-Button aus CReaM im Einsatz war, muss dieser in Ihrer Anwendung durch den neuen Login-Button aus DocCheck Access ersetzt werden.
Prüfen Sie pro migriertem Login-Client, dass Ihre Anwendung Folgendes verwendet:
- die neue Login-Client-ID
- das neue Login-Client-Secret
- das aktuelle Button-Markup
- das aktuelle Script-Tag
# OAuth2-Anpassungen
Prüfen Sie die OAuth2-Logik Ihrer Anwendung und ersetzen Sie die Legacy-Endpunkt-URLs.
Verwenden Sie die neuen Endpunkte:
| Endpunkt | URL |
|---|---|
| Authorization-Endpunkt | https://auth.doccheck.com/{language}/authorize |
| Access-Token-Endpunkt | https://auth.doccheck.com/token |
| Userdaten-Endpunkt | https://auth.doccheck.com/api/users/data |
Eine vollständige Übersicht finden Sie unter Überblick Endpunkte.
# Beispiele, Vorlagen und Endpunkt-Tests
Für Implementierung, User-Flow-Verständnis und Endpunkt-Tests stehen zusätzliche Ressourcen zur Verfügung:
- Demo Projekt: Beispielanwendung, um User Flows nachzuvollziehen und zu sehen, wie eine Implementierung aussehen kann.
- Postman Collection: Collection zum Testen der Endpunkte mit Ihrem eigenen Login-Client.
- PHP Provider: Codebeispiel bzw. Vorlage für einen DocCheck Auth Flow in PHP.
- Mobile Login: React-Native-Beispiel bzw. Vorlage für einen DocCheck Auth Flow in mobilen Anwendungen.
# Routing-Umstellung
Legacy-Routing durch DocCheck wird im neuen System nicht mehr verwendet.
Wenn Ihre bisherige Implementierung von Routing nach Beruf, Land, Sprache oder eigenen URL-Parametern abhängig war, verlagern Sie diese Logik in Ihre eigene Anwendung:
- Nutzen Sie den
state-Parameter, um alle notwendigen Parameter durch den Login zu übergeben. - Werten Sie den zurückgegebenen
state-Wert nach dem Login in Ihrer Anwendung aus. - Für Routing auf Basis von Userdaten fragen Sie die benötigten Scopes an und werten die zurückgegebenen Daten aus dem Userdaten-Endpunkt aus.
Wichtig
Parameterübergabe ist nur über state möglich und steht ab Economy zur Verfügung. Übergeben Sie keine personenbezogenen Daten in state oder redirect_uri.
# Userdaten und Scope-Mapping
Vergleichen Sie die alten und neuen Userdaten-Payloads und passen Sie alle Abhängigkeiten in Ihrer Anwendung an.
Wichtige Änderungen:
unique_idbleibt bei realen Usern stabil.- Neue Testnutzer und Firmenpasswörter verwenden dasselbe Format wie die bisherige Unique-ID.
- ID-Mappings haben sich für
country_id,profession_idunddiscipline_idgeändert. activity_idist neu.
Details zum Mapping und Payload-Beispiele finden Sie unter Data Mapping & Payload.
# Testen und ersetzen
Vor dem Go-live:
- Testen Sie den neuen Login-Button in Ihrer Testumgebung.
- Testen Sie OAuth2-Tokenaustausch und Userdaten-Abruf.
- Testen Sie Routing und
state-Handling, sofern verwendet. - Testen Sie mit neuen Testnutzern.
- Testen Sie die Endpunkte bei Bedarf mit der Postman Collection.
- Vergleichen Sie die zurückgegebenen Userdaten mit den Anforderungen Ihrer Anwendung.
- Ersetzen Sie die alte Implementierung, wenn alle Prüfungen erfolgreich sind.