Build a Custom App Card from Scratch (Part 2) | OAuth Config & App Card Install

Bri, a HubSpot Developer Advocate, walks through OAuth setup and app card installation for a custom HubSpot integration. The tutorial covers the authorization workflow, code configuration, and how to install your app in HubSpot's developer test portal.
Sie verwenden es jeden Tag, aber wie funktioniert es wirklich? Lassen Sie uns OOTH genauer betrachten und die Geheimnisse für die Erstellung sicherer Integrationen mit HubSpot lüften. Wenn Sie unser letztes Video gesehen haben, haben wir damit begonnen, eine öffentliche App Karte für die globale Verfügbarkeit von Kontakten mithilfe der UI Erweiterungen von HubSpot zu erstellen. Unser HubSpot Projekt ist eingerichtet, die öffentliche App mit UI Erweiterungen initialisiert, Projektdateien via CLI hochgeladen. Wir haben sogar genau untersucht und wo Sie Ihre Projekt und App Einstellungen in Ihrem HubSpot Entwicklerkonto finden und verwalten können. Jetzt kommen wir zum nächsten wichtigen Schritt. Wir verwenden OOTH, um unsere öffentliche App sicher zu installieren und unsere Erweiterungskarte direkt in einem HubSpot Portal einzurichten und auszuführen. Bevor wir unsere App installieren können, müssen wir jedoch über ein äußerst wichtiges Konzept OOTH Wenn Sie damit noch nicht vertraut sind, machen Sie sich keine Sorgen. Hallo, ich bin Bri Developer Advocate hier bei HubSpot. Ich werde euch die wichtigsten Dinge erklären, die ihr als Entwickler, der eine öffentliche App auf HubSpot erstellt, wissen müsst. OOTH ist im Kern ein Industriestandard Autorisierungsprotokoll. Einfach ausgedrückt ist dies eine sichere Möglichkeit für eine Anwendung wie unsere die Berechtigung für den Zugriff auf die Daten eines Nutzers, wie zb seine HubSpot Kontakte von einem anderen Dienst aus zu erhalten, ohne dass dessen tatsächliche Anmeldedaten erforderlich sind. Man kann es sich wie einen digitalen Parkservice vorstellen. Dem Parkservice gibt man nur den Autoschlüssel zum Parken, nicht den ganzen Schlüsselbund. Die größten Vorteile von ooth sind Sicherheit und Vertrauen. Nutzer müssen keine sensiblen Passwörter teilen und können ihrer App sehr spezifische Berechtigungen erteilen. Wenn Ihre App also nur Kontaktdaten lesen muss, kann der Nutzer nur diese Berechtigung erteilen und nicht den Zugriff auf sein gesamtes HubSpot Portal. Wie funktioniert dieser Handshake nun genau? Lassen Sie uns einen allgemeinen OOTH Autorisierungsworkflow durchgehen. Stellen Sie sich das als Weiterleitungen und Austausch vor. Zuerst Zuerst haben wir die Autorisierungsanfrage. Der Kunde initiiert die App Installation, unabhängig davon, ob er auf eine Schaltfläche zum Installieren der App klickt oder ob dies über einen Direktlink erfolgt. Er wird zum Autorisierungsbildschirm von HubSpot weitergeleitet. Als nächstes haben wir die Nutzereinwilligung. HubSpot zeigt die angeforderten Bereiche Ihrer App an. App Installation bestätigt die Nutzer Zustimmung zu den Berechtigungen. Dann haben wir die Erteilung des Autorisierungscodes. HubSpot leitet den Browser des Nutzers dann zurück zur vorkonfigurierten Weiterleitungs URI ihrer App, bei der es sich um eine bestimmte URL in Ihrem Buckend handelt. Diese Weiterleitung enthält einen temporären Autorisierungscode. Dann folgt der Tokenaustausch. Das Backend Ihrer App erhält diesen Autorisierungscode. Es sendet dann sofort eine sichere direkte Anfrage an den Tokenendpunkt von HubSpot und tauscht den Autorisierungscode zusammen mit Ihrer Client ID und Ihrem Client Geheimnis gegen zwei wichtige Token, ein Zugriffstken und ein Aktualisierungsstoken. Ihr Zugriff stoken der kurzlebige Schlüssel Ihrer App für HubSpot API Aufrufe. Dieses Portal, ein langlebiges Aktualisierung beschafft automatisch neue Zugriffstucken bei Ablauf der alten, sodass keine erneute Benutzerauthentifizierung nötig ist. Nun speichert Ihr Backend diese Token sicher und verwendet das aktuelle Zugriffstoken, um bei Bedarf authentifizierte Aufrufe der APIs von HubSpot durchzuführen. Das klingt jetzt vielleicht nach vielen beweglichen Teilen, aber keine Sorge. Wir werden das HubSpot Ooth Node.js Quickert Repository von GitHub nutzen für Entwickler wie uns. Dieses Repo ermöglicht die schnelle Einrichtung temporärer server für den OAuth Workflow. Folgen Sie dem Link hier oder in der Beschreibung zum Repository. Wir werden es lokal klonen. Für dieses Beispiel werde ich es im Stammverzeichnis unseres bestehenden Projekts klonen. AES gibt also zwei Möglichkeiten, dieses Repository auszuführen. Man kann es lokal mit Node JS und Yan laufen lassen. Wenn Sie diese Programme noch nicht installiert haben, sollten Sie dies jetzt tun. Oder Sie können dieses Projekt über einen Docker Container ausführen. Heute werde ich ersteres tun. Nach dem Klonen installieren Sie die erforderlichen Abhängigkeiten. Mit Yan Install öffnen Sie nun Index JS. Oben sehen Sie grundlegende Node JS Einstellungen, etwa Express für den Server. Das Herzstück unserer HubSpot App Konfiguration beginnt jedoch in Zeile 14. Hier stellen wir sicher, dass wir über die richtigen Anmeldedaten die Client ID und das Client Geheimnis aus unserer Umgebungsdatei verfügen. Ich zeige Ihnen gleich genau, wo Sie diese finden. Als nächstes definieren wir unsere Bereiche. Diese teilen HubSpot explizit mit, welche Berechtigungen unsere App anfordert. Als nächstes definieren wir die Umleitungs URI. Dies ist die genaue URL auf unserem lokalen server, an die HubSpot den Browser des Nutzers zurücksendet, nachdem dieser die Autorisierung erteilt hat. Für die lokale Entwicklung ist dies der Callback Localhost 3000 O. Diese URL muss in Ihren öffentlichen App Einstellungen in HubSpot genau registriert sein. Verfolgen wir nun den tatsächlichen Ooth Ablauf durch den Code, der diese Schritte abbildet, die wir zuvor besprochen haben. Zuerst kommt die Autorisierungsanforderung. Der Ablauf. Ein Nutzer wie wir greift auf die lokale Installationsroute zu. Diese Route erstellt die vollständige HubSpot Autorisierungs URL. Unser Server leitet dann einfach den Browser des Nutzers an diese URL weiter. Ihre App sagt HubSpot, dieser Nutzer will sie installieren. Erlaubnis nötig. Als nächstes folgt die Einwilligung des Nutzers. Beachten Sie, dass es für diesen zweiten Schritt keinen Codeblock gibt, da dieser schritt vollständig in HubSpot stattfindet. Ruft der Nutzer Browser HubSpots Autorisierungsseite auf, zeigt HubSpot einen Einwilligungsbildschirm mit den von Ihrer App benötigten Berechtigungen. Als nächstes folgt der Empfang des Autorisierungscodes. Vorausgesetzt, der Nutzer Stimmt zu, leitet HubSpot den Browser zurück an unsere Umleitungs URI, die unsere Ooth Callback Route ist. Diese Route liefert bei Aufruf einen code in den REG Parametern. Dieser Code, von HubSpot gerade erhalten, autorisiert temporär und bestätigt die Nutzererlaubnis. Jetzt tauschen wir diesen Code gegen unsere Token aus. Wenn wir einen Code erhalten, erstellen wir sofort ein O Code Proof Objekt. Dieses Objekt enthält den Grantyp, also den Autorisierungscode, unsere Client ID, das Client Geheimnis und die Umleitungs URI. Dann senden wir eine Server zu Server Post Anforderung an den Token Endpunkt von HubSpot und senden diesen auf Code Proof im Anforderungstext. HubSpot validiert unsere Client ID und das Client Geheimnis, um sicherzustellen, dass es sich tatsächlich um unsere App handelt, die den Token anfordert, und tauscht den temporären Autorisierungscode gegen das tatsächliche Zugriffstucken und Aktualisierungstucken aus. Sobald wir diese beiden Token haben, können wir sie tatsächlich verwenden, wie wir es in der GitKontakt Funktion tun. Schließlich können Sie in der getContact Funktion sehen, dass wir unseren neu erworbenen Zugriffstucken verwenden. Wir geben ihn einfach im Autorisierungsheader unserer Anforderung für die CRM API von HubSpot an. Dies beweist HubSpot, dass unsere App über die Berechtigung verfügt, auf die Daten für dieses bestimmte Portal zuzugreifen. Diese Datei index JS vereinfacht den Schnellstart und bietet uns gleichzeitig einen praktischen Einblick in jeden Schritt des Ooth Autorisierungsablaufs von HubSpot. Wir müssen nur noch einen Schritt ausführen, um sicherzustellen, dass OOTH für unsere öffentliche Kontaktverfügbarkeitskarte konfiguriert ist. Wir erstellen eine Datei für unsere Geheimnisse und Bereiche. Kopieren Sie im Stammverzeichnis des OOTH Verzeichnisses den Inhalt der Beispielumgebungsdatei aus der README Datei im OOTH Projekt und von GitHub. Ihre Client ID und Ihr Client Geheimnis finden Sie im Entwicklerportal unter Apps, Ihrer aktuellen App und dem Reiter O. Kopieren Sie diese in Ihre Umgebungsdatei. Werfen wir nun einen kurzen Blick auf die Bereiche. Diese Vorlage bietet uns Lese und Schreibberechtigungen für Kontakte und Formulare. Für dieses Beispiel benötigen wir derzeit nur Lese und Schreibberechtigungen für Kontakte. Daher können wir Formulare entfernen. Wichtig zu beachten ist, dass beim Ändern von Berechtigungen im OOTH Workflow diese auch im Scope Array in der öffentlichen Datei App JSON in Ihrem HubSpot Projekt in Ihren UI Erweiterungen widergespiegelt werden sollten. Mit OOTH eingerichtet installieren wir die App Karte aus dem letzten Video. Haben Sie nicht gesehen, wie wir sie erstellt haben? Der Link in der Beschreibung führt zum Video. Öffnen Sie ein Terminal im Ooth-Verzeichnis und führen Sie Jahnstart aus, um den Server zu starten. Ein Browser öffnet sich mit Link zur App Installation. Klicken Sie auf den Link. Daraufhin wird der HubSpot Bildschirm angezeigt, auf dem Sie ein Portal auswählen können. Bei dieser Instanz möchten wir sicherstellen, dass wir die App in Ihrem Entwicklertest Portal installieren. Akzeptieren Sie die Berechtigungen. Kontaktname und Autorisierungscode erscheinen auf dem OOTH Callback Bildschirm. Dies bestätigt, dass unsere App erfolgreich im Konto installiert wurde. Wechseln wir nun zum Entwicklertest Konto im Browser. Diese App ist für die Ausführung im Kontaktobjekt konfiguriert. Wir öffnen also einen Kontakt und wechseln zu Datensatz anpassen. Ich aktualisiere die Standardansicht. Jetzt können wir unserem Kontaktdatensatz Karten hinzufügen. Wenn Sie Karte hinzufügen auswählen und nach Apps filtern, finden Sie das Beispiel der hello Public App, das wir zuvor erstellt haben. Fügen wir nun diese Karte hinzu, speichern Sie die Änderungen zurück zur Ansicht. Jetzt sollten Sie Ihre brandneue hello Public App im CRM sehen. Jetzt aktualisieren wir sie. Wechseln Sie zu Ihrem Code Editor und wir öffnen eine neue Terminalinstanz im Verzeichnis. Kontaktverfügbarkeit erfolgreich konfiguriert, unsere öffentliche App Karte in einem Entwicklertestkonto installiert und Ihre Sichtbarkeit im CRM bestätigt. Und am wichtigsten ist, dass Sie jetzt wissen, wie Sie Ihre lokale Entwicklerumgebung mit HS Project dev einrichten, um Ihre Erweiterungsänderungen sofort zu sehen. Wir richten unsere Next JS App ein, um benutzerdefinierte API Endpunkte für die Verarbeitung unserer Verfügbarkeitslogik zu erstellen, einen lokalen Proxy für die nahtlose lokale Entwicklung mit HubSpot Fetch zu konfigurieren und schließlich unser Next JS Backend of Fashell bereitzustellen, um unsere Architektur zu vervollständigen. Machen Sie sich bereit, unsere UI Erweiterung mit Echtzeitdaten zum Leben zu erwecken. Die Dokumentation, das GitHub Repository für dieses Projekt und mehr finden Sie in der folgenden Beschreibung. Abonnieren Sie unseren YouTube Kanal und aktivieren Sie die Benachrichtigungen, um über neue Videos wie diese und andere für HubSpot Entwickler informiert zu werden. Bis zum nächsten Mal.










