GoodBarber Custom Code mit angemeldetem Nutzer testen

Written by Mathieu Poli on Freitag 26 Juni 2026

Soll Ihr GoodBarber Custom Code sich für einen angemeldeten Nutzer anders verhalten – Premium-Inhalte anzeigen, ein Mitglied mit Namen begrüßen, einen Bereich vor anonymen Besuchern verbergen? Egal, ob Sie diesen Code selbst geschrieben oder ihn mit dem AI Extension Builder generiert haben – er fragt die App API über gb.user.getCurrent(), wer angemeldet ist. Die Vorschau im Back Office kennt jedoch keine echte Anmeldung – bei Membership-Apps landet dieser Aufruf daher immer im Fehlerpfad. Diese Anleitung erklärt, wie sich der aktuelle Nutzer in der Vorschau für jeden App-Typ verhält, und zeigt Ihnen einen Copy-and-paste-Weg, um als angemeldetes Member zu testen.

Viel Custom Code muss wissen, wer die App gerade benutzt: um Premium-Inhalte anzuzeigen, Mitglieder mit Namen zu begrüßen, einen Bereich vor anonymen Besuchern zu verbergen oder einen Checkout anzupassen. Die GoodBarber App API liefert Ihnen den aktuellen Nutzer über gb.user.getCurrent().

Und Custom Code schreiben Sie längst nicht mehr nur von Hand. Mit dem AI Extension Builder von GoodBarber beschreiben Sie den gewünschten Bereich in natürlicher Sprache, und der Assistent generiert die Extension für Sie – Code, der sich direkt an dieselbe GoodBarber App API anbindet. Ob von Hand geschrieben oder KI-generiert: Er ruft gb.user.getCurrent() auf die gleiche Weise auf, und Sie testen ihn auf die gleiche Weise. Diese Anleitung gilt also gleichermaßen, ob Sie den Code selbst getippt oder per Prompt erzeugt haben.

Doch hier ist der Haken, auf den jede Entwicklerin und jeder Entwickler früher oder später stößt: Innerhalb der Vorschau im Back Office gibt es keinen angemeldeten Nutzer. Die Vorschau ist nur ein Rendering Ihrer App – es gibt keinen Anmeldebildschirm, keine Session, nichts, woran man sich authentifizieren könnte.

Für die meisten App-Typen löst GoodBarber das im Hintergrund für Sie, sodass das Testen „als angemeldeter Nutzer" einfach funktioniert. Für die Membership-Extension ist das nicht der Fall – und zwar mit Absicht. Dieser Artikel zeigt Schritt für Schritt, wie sich der aktuelle Nutzer in der Vorschau je nach App-Typ verhält, und gibt Ihnen einen einfachen Copy-and-paste-Weg an die Hand, um den kniffligsten Fall zu testen: ein angemeldetes Member.

Kurze Auffrischung: gb.user.getCurrent()

Mit der GoodBarber App API kann Ihr Custom Code über eine einzige Methode fragen „wer benutzt die App gerade?":

gb.user.getCurrent(
    (user) => {
        // Ein Nutzer ist angemeldet.// `user` ist ein GBUser-Objekt — hier lesen Sie seine Attribute aus.
        console.log(user.email);
    },
    (error) => {
        // Es ist kein Nutzer angemeldet.
        console.log(`Response status: ${error.code}`);
        console.log(`Response message: ${error.message}`);
    }
);

Sie erwartet zwei Callbacks: einen Success-Callback (wird mit einem GBUser-Objekt aufgerufen, wenn jemand angemeldet ist) und einen Error-Callback (wird aufgerufen, wenn niemand angemeldet ist). Sie ist Callback-basiert – sie gibt keinen Wert und kein Promise zurück.

Das GBUser-Objekt hat je nach App-Typ eine andere Form

Das GBUser-Modell trägt eine api_version-Property, die Ihnen verrät, welche Art von App es erzeugt hat:

`api_version`	App-Typ
`1`	Content-App + Authentication-Extension
`2`	eCommerce-App
`3`	Content-App + Membership-Extension

Welche Attribute vorhanden sind, hängt von dieser Version ab. Für eine Membership-App (api_version: 3) sieht ein GBUser so aus:

{
    id: 123,
    api_version: 3,
    login: "member@example.com",
    email: "member@example.com",
    username: "John Doe",
    firstname: "John",
    lastname: "Doe",
    picture_url: "https://example.com/picture.jpg",
    access_levels: ["premium"]   // 👈 das entscheidende Feld bei Membership
}

Das Array access_levels macht Membership besonders: Es listet die Zugriffsebenen auf, die der Nutzer aktuell besitzt. Genau danach verzweigt Ihr Custom Code fast immer („hat dieser Nutzer premium? Dann zeige den Bonus-Inhalt").

In der Praxis liest Ihr Code access_levels, um zu entscheiden, was angezeigt wird:

gb.user.getCurrent(
    (user) => {
        if (user.access_levels.includes("premium")) {
            console.log("Mitglied hat premium — Premium-Inhalt anzeigen");
        } else {
            console.log("Angemeldet, aber kein premium — Upgrade-Hinweis anzeigen");
        }
    },
    (error) => {
        console.log("Niemand angemeldet — Login-Aufforderung anzeigen");
    }
);

Behalten Sie das im Hinterkopf – genau diesen Code wird das Mock-Objekt weiter unten bedienen.

Wie sich der aktuelle Nutzer in der Vorschau verhält

Die Vorschau im Back Office ist eine Sandbox. Sie rendert Ihre App, besitzt aber keinen Anmeldemechanismus – darin lässt sich kein echter Nutzer authentifizieren.

Damit die Entwicklung trotzdem angenehm bleibt, injiziert GoodBarber für manche App-Typen einen Fake-Nutzer, sodass getCurrent()etwas zurückgibt, mit dem Sie arbeiten können:

App-Typ	In der Vorschau liefert `getCurrent()`…
Authentication-Add-on (`api_version: 1`)	✅ Gibt automatisch einen Fake-Nutzer zurück – Ihr Success-Callback feuert.
eCommerce-App (`api_version: 2`)	✅ Gibt automatisch einen Fake-Kunden zurück – Ihr Success-Callback feuert.
Membership-Extension (`api_version: 3`)	❌ Gibt nichts zurück – Ihr Error-Callback feuert mit `"There's no user logged in the app."`

Wenn Ihre App also Authentication oder eCommerce nutzt, können Sie Ihre Logik für angemeldete Nutzer direkt in der Vorschau testen – ein Fake-Nutzer wird Ihnen gratis übergeben, ganz ohne Einrichtung.

Nutzt Ihre App die Membership-Extension, ist es anders: Es wird kein Fake-Nutzer injiziert. Wenn Ihr Success-Callback in der Vorschau nie feuert und Sie ständig im Fehlerpfad landen, ist das so vorgesehen – es gibt schlicht keinen aktuellen Nutzer, der zurückgegeben werden könnte, und anders als bei den beiden anderen App-Typen wird auch keiner für Sie simuliert.

Der Rest dieses Artikels konzentriert sich auf diesen Membership-Fall, denn er ist derjenige, der etwas Handarbeit erfordert. Sie haben zwei Möglichkeiten, ihn zu lösen.

Option 1 – In der MyGoodBarber App testen (reale Bedingungen)

Am originalgetreuesten testen Sie, indem Sie Ihre App in der MyGoodBarber App ausführen (verfügbar für iOS und Android). Sie lädt Ihre echte App mit dem echten Login-Flow und dem echten Backend. Sie melden sich als echtes Mitglied an, und getCurrent() gibt Ihren echten GBUser mit Ihren echten access_levels zurück.

Nutzen Sie das, wenn Sie den gesamten Flow vor der Veröffentlichung Ende-zu-Ende prüfen möchten. Das kommt der Produktion am nächsten.

Der Nachteil: Die Feedback-Schleife ist langsamer. Eine CSS-Anpassung oder eine bedingte Verzweigung lässt sich damit nicht so schnell iterieren wie in der Vorschau. Genau dafür gibt es Option 2.

Option 2 – getCurrent() in der Vorschau mocken

Für schnelles Iterieren können Sie gb.user.getCurrentvorübergehend ersetzen – durch eine eigene Version, die einen Fake-Member Ihrer Wahl zurückgibt. Ihre eigentliche Logik bleibt dabei exakt gleich – Ihr Custom Code ruft gb.user.getCurrent(success, error) weiterhin wie gewohnt auf. Sie tauschen nur aus, was die Methode tut, während Sie testen.

Schritt 1 – Das Mock-Objekt an den Anfang Ihres Codes setzen

Fügen Sie diesen Block ganz an den Anfang des JavaScripts Ihres Custom Code ein, vor jedem Aufruf von getCurrent():

// ⚠️ NUR ZUM TESTEN IN DER VORSCHAU — vor der Veröffentlichung entfernen (oder auf false setzen)!const PREVIEW_TESTING = true;

if (PREVIEW_TESTING && typeof gb !== "undefined" && gb.user) {
    gb.user.getCurrent = function (successCallback, errorCallback) {
        const fakeUser = {
            id: "123",
            api_version: 3,
            login: "member@example.com",
            email: "member@example.com",
            username: "Test Member",
            firstname: "Test",
            lastname: "Member",
            picture_url: "",
            access_levels: ["premium"]   // 👈 hier ändern, um andere Fälle zu testen
        };
        successCallback(fakeUser);
    };
}

💡 "premium" ist nur ein Beispiel. Verwenden Sie die echten Zugriffsebenen-Bezeichner, die in Ihrer App konfiguriert sind – sonst greifen Ihre Bedingungen ins Leere.

Sie fragen sich vielleicht: Kann mein Code nicht einfach die Vorschau erkennen und nur dort mocken? Leider nein – es gibt kein zuverlässiges Signal für Ihren Custom Code, das sagt „das ist die Vorschau" (gb.platform() gibt in der Vorschau "web" zurück, genau wie eine echte PWA in der Produktion), und allein aus getCurrent ist die Vorschau nicht von einem tatsächlich abgemeldeten Nutzer zu unterscheiden (beide landen im Error-Callback). Deshalb verwenden wir ein Flag, das Sie von Hand umlegen: Es ist explizit und kann in der Produktion nicht versehentlich ausgelöst werden.

Das war's. Ab jetzt erhält Ihr onUserFound-Callback überall dort in Ihrem Custom Code, wo Sie

gb.user.getCurrent(onUserFound, onNoUser);

…aufrufen, den obigen Fake-Member – genau so, als wäre ein echtes premium-Mitglied angemeldet. Ihre Business-Logik ändern Sie überhaupt nicht; Sie haben lediglich den Mock-Block obendrauf gesetzt.

Schritt 2 – Die Fälle testen, auf die es ankommt

Der ganze Sinn von Membership-Code ist es, auf unterschiedliche Nutzer zu reagieren. Passen Sie das Mock-Objekt einfach an, um jedes Szenario abzudecken:

Ein zahlendes Mitglied (mit Zugriffsebenen):

access_levels: ["premium"]

Ein angemeldeter Nutzer ohne Abonnement:

access_levels: []

Mehrere Zugriffsebenen gleichzeitig:

access_levels: ["free", "premium", "vip"]

Niemand ist angemeldet – hier mocken Sie statt des Success- den Error-Pfad:

gb.user.getCurrent = function (successCallback, errorCallback) {
    errorCallback({ code: 1, message: "There's no user logged in the app." });
};

Wechseln Sie zwischen diesen Fällen hin und her, um sicherzustellen, dass sich Ihr Custom Code in jedem Zustand korrekt verhält – nicht nur im Idealfall.

Schritt 3 (optional) – Auch gb.membership.getAccessLevels() mocken

Mancher Membership-Code liest die Zugriffsebenen über die dedizierte Membership-Methode statt über das Nutzerobjekt:

gb.membership.getAccessLevels(
    (access_levels) => { console.log(access_levels); },
    (error) => { console.log(error.message); }
);

Falls Sie sie nutzen, mocken Sie sie auf dieselbe Weise:

if (PREVIEW_TESTING && typeof gb !== "undefined" && gb.membership) {
    gb.membership.getAccessLevels = function (successCallback, errorCallback) {
        successCallback(["premium"]);
    };
}

⚠️ Vor der Veröffentlichung: das Mock-Objekt abschalten

Das ist die eine Regel, die Sie nicht überspringen dürfen. Das Mock-Objekt ist eine Entwicklungs-Krücke – es darf niemals in die Produktion gelangen. Wenn Sie es ausliefern, wird jeder Nutzer der App als Ihr Fake-premium-Mitglied behandelt, ganz gleich, wofür er tatsächlich bezahlt hat.

Zwei sichere Gewohnheiten:

Halten Sie alles hinter dem einzelnen PREVIEW_TESTING-Flag und setzen Sie es vor der Veröffentlichung auf false.
Noch besser: Löschen Sie den Mock-Block vollständig, sobald Sie mit dem Testen fertig sind.

Wenn PREVIEW_TESTING auf false steht (oder der Block entfernt ist), fällt gb.user.getCurrent auf die echte Implementierung von GoodBarber zurück, und Ihr Custom Code arbeitet mit tatsächlich angemeldeten Mitgliedern.

Bereit zum Ausprobieren? Öffnen Sie den Bereich Custom Code in Ihrem GoodBarber Back Office, fügen Sie den Mock-Block oben in Ihr JavaScript ein und setzen Sie die access_levels für den Fall, den Sie testen möchten. Wenn alles wie gewünscht funktioniert, setzen Sie PREVIEW_TESTING auf false (oder löschen Sie den Block) und veröffentlichen Sie. Die vollständige Referenz finden Sie in der App-API-Dokumentation.

Und wenn Sie die Extension lieber nicht von Hand schreiben möchten, kommt genau hier der AI Extension Builder ins Spiel: Beschreiben Sie den gewünschten Bereich in natürlicher Sprache, und er generiert die Extension, bindet sie an die hauseigenen APIs von GoodBarber an und stellt sie live in Ihrer App dar. Er baut auf derselben App API auf – die obige Technik steht Ihnen also jederzeit zur Verfügung, wenn Sie eine Vorschau davon möchten, wie sich Ihre Extension für ein angemeldetes Mitglied verhält.

Weiterführende Lektüre

gb.user.getCurrent – den aktuell angemeldeten Nutzer abrufen.
GBUser – das Nutzermodell und wie sich seine Attribute je nach api_version ändern.
gb.membership.getAccessLevels – Zugriffsebenen direkt auslesen (nur mit dem Memberships-Add-on verfügbar).
GoodBarber für Entwickler: mehr Freiheit und Werkzeuge für Power-User – was Sie über den No-Code-Editor hinaus bauen können.

Zusammenfassung

In der Vorschau im Back Office gibt es keine echte Anmeldung.
Bei Authentication- und eCommerce-Apps injiziert GoodBarber automatisch einen Fake-Nutzer, sodass das Testen als angemeldeter Nutzer einfach funktioniert.
Bei der Membership-Extension wird kein Fake-Nutzer bereitgestellt – getCurrent() landet im Error-Callback.
Um in der Vorschau schnell zu testen, überschreiben Sie gb.user.getCurrent vorübergehend (und gb.membership.getAccessLevels, falls Sie es nutzen), sodass ein Fake-Member mit den access_levels zurückgegeben wird, die Sie testen möchten.
Für eine echte Ende-zu-Ende-Prüfung führen Sie Ihre App in der MyGoodBarber App aus.
Entfernen Sie das Mock-Objekt immer vor der Veröffentlichung.

FAQ

Warum gibt gb.user.getCurrent() in der Vorschau für meine Membership-App einen Fehler zurück?

Weil die Vorschau im Back Office keinen Anmeldemechanismus hat und GoodBarber für Membership-Apps (api_version: 3) keinen Fake-Nutzer injiziert. Da niemand angemeldet ist, ruft die Methode Ihren Error-Callback mit "There's no user logged in the app." auf – das ist erwartetes Verhalten, kein Bug.

Warum funktioniert derselbe Code in der Vorschau für eine Authentication- oder eCommerce-App?

Für Authentication- (api_version: 1) und eCommerce-Apps (api_version: 2) injiziert GoodBarber in der Vorschau automatisch einen Fake-Nutzer (bzw. Fake-Kunden), sodass Ihr Success-Callback ohne jede Einrichtung feuert.

Wie teste ich ein angemeldetes Mitglied, ohne meine App zu veröffentlichen?

Führen Sie Ihre App entweder in der MyGoodBarber App (iOS/Android) aus, um unter realen Bedingungen zu testen, oder überschreiben Sie gb.user.getCurrent in Ihrem Custom Code vorübergehend, sodass ein Fake-Member mit den access_levels zurückgegeben wird, die Sie testen möchten.

Was ist access_levels im GBUser-Objekt?

Es ist ein Array der Zugriffsebenen, die ein Membership-Nutzer aktuell besitzt (zum Beispiel ["premium"]). Ihr Custom Code verzweigt typischerweise danach, um zu entscheiden, welche Inhalte angezeigt werden. Ein leeres Array ([]) bedeutet einen angemeldeten Nutzer ohne aktives Abonnement.

Gibt gb.user.getCurrent() ein Promise zurück?

Nein. Die Methode ist Callback-basiert: Sie übergeben einen Success-Callback und einen Error-Callback. Sie gibt keinen Wert zurück, Sie können sie also nicht mit await aufrufen.

Was passiert, wenn ich vergesse, das Mock-Objekt vor der Veröffentlichung zu entfernen?

Jeder Nutzer Ihrer App wird als das fest verdrahtete Fake-Mitglied behandelt – alle erhielten etwa premium-Zugriff, unabhängig davon, wofür sie tatsächlich bezahlt haben. Setzen Sie PREVIEW_TESTING immer auf false oder löschen Sie den Mock-Block, bevor Sie veröffentlichen.