Ich verwende WordPress + WooCommerce in Kombination mit der WP-API als Backend für meine mobile E-Commerce-App.
Mein Ziel ist es, innerhalb der App ein soziales Login (über Facebook, Twitter, Google usw.) anzubieten, um sich zu registrieren/anzumelden und dann die WooCommerce-API zu verwenden, um z. B. alle Bestellungen dieses authentifizierten Benutzers zu erhalten.
Aktuell ist mein Plan:
- Verwenden Sie ein Client-SDK, damit sich der Benutzer beispielsweise mit seinem FB-Konto anmelden kann
- Aus Schritt 1 erhalte ich z. B. den Benutzernamen, die E-Mail-Adresse und die FB-ID, die an einen benutzerdefinierten Endpunkt gesendet werden, um den Benutzer zur WordPress-DB hinzuzufügen (wie z https://github.com/royboy789/wp-api-social-login)
- Erstellen Sie einen benutzerdefinierten Endpunkt für Bestellungen mit WP-API (z. B.: …/orders)
- Überprüfen Sie in der Endpunktfunktion, ob der Benutzer authentifiziert ist
- Wenn der Benutzer authentifiziert ist, gibt der Endpunkt die Bestellungen des Benutzers mithilfe eines WooCommerce-API-Wrappers zurück (https://github.com/kloon/WooCommerce-REST-API-Client-Library)
Aber ich kämpfe bei # 3, weil ich nicht wirklich weiß, wie ich überprüfen soll, ob der Benutzer authentifiziert ist.
Ich habe darüber nachgedacht, einen weiteren Endpunkt zu erstellen, der den OAuth-Autorisierungsserver kontaktiert, um die Anmeldeinformationen des Benutzers zu überprüfen, z. B. mit dem Zugriffstoken von Facebook. Und wenn die Prüfung gültig ist, würde ich ein benutzerdefiniertes Zugriffstoken für meine API erstellen, indem ich ein Hashing der Benutzer-ID, E-Mail usw. verwende, das an die Client-App zurückgesendet wird. Dieser Access Token wird dann bei jedem Aufruf meiner API verwendet, die dann die User ID aus dem gehashten Token ausliest und zB alle Bestellungen für diesen User zurückliefert.
Aber irgendwie fühlt sich das einfach nicht richtig an. Vor allem, weil ich auf diese Weise einen endlos lebenden Access Token erstellen würde …