---
title: "GoodBarber Custom Code mit angemeldetem Nutzer testen"
description: "Soll Ihr GoodBarber Custom Code sich für einen angemeldeten Nutzer anders verhalten – Premium-Inhalte anzeigen, ein Mitglied mit Namen begrüßen, einen Bereich v"
canonical_url: "https://de.goodbarber.com/blog/goodbarber-custom-code-mit-angemeldetem-nutzer-testen-a1391/"
lang: de
date: 2026-06-26
last_updated: 2026-07-17
---

# GoodBarber Custom Code mit angemeldetem Nutzer testen

[Zurück](/blog/mach-es-r13/)

# GoodBarber Custom Code mit angemeldetem Nutzer testen

Written by [Mathieu Poli](https://de.goodbarber.com/blog/author/mathieu-poli/)  on Freitag 26 Juni 2026· Letzte Aktualisierung: Freitag 17 Juli 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.

![](https://cmsphoto.ww-cdn.com/superstatic/129568/art/grande/97133653-67674254.jpg?v=1782463734.780426)

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](https://de.goodbarber.com/blog/ai-extension-builder-sektionen-mit-ki-erstellen-ohne-zu-programmieren-a1341/)** 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](https://de.goodbarber.com/blog/das-abonnementsystem-ist-da-a1078/)** 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.getCurrent` **vorü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:

1. Halten Sie alles hinter dem einzelnen `PREVIEW_TESTING`-Flag und setzen Sie es vor der Veröffentlichung auf `false`.
2. 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](https://app.goodbarber.dev/v2/documentation/).

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`](https://app.goodbarber.dev/v2/documentation/#tag/user-methods/operation/gb.user.getCurrent) – den aktuell angemeldeten Nutzer abrufen.
- [`GBUser`](https://app.goodbarber.dev/v2/documentation/#tag/user-models/operation/GBUser) – das Nutzermodell und wie sich seine Attribute je nach `api_version` ändern.
- [`gb.membership.getAccessLevels`](https://app.goodbarber.dev/v2/documentation/#tag/membership-methods/operation/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](https://de.goodbarber.com/blog/goodbarber-open-mehr-freiheit-f%C3%BCr-entwickler-und-fachanwender-a1233/) – 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.

![Mathieu Poli](https://blog.goodbarber.com/_public/profile/65/6553d00ecdbe15f8aac2da7dddcff47648fdd791-default.jpg)

Über den Autor[Mathieu Poli](https://de.goodbarber.com/blog/author/mathieu-poli/)Head of Frontend Engineering

Ich bin Head of Frontend Engineering bei GoodBarber.

Ich leite die Teams, die die Rendering-Engines im Herzen unserer No-Code-Plattform entwickeln: Sie sind es, die die Projekte unserer Nutzer zum Leben erwecken und in native Apps verwandeln – flüssig und sorgfältig gestaltet. Alles, was man auf dem Bildschirm sieht und bedient, geht durch ihre Hände.
Als Pionier des mobilen No-Code, begeistert von Softwarearchitektur und Produktdesign, unterrichte ich außerdem an Universitäten und privaten Hochschulen.

Hier schreibe ich über Frontend-Engineering, Produktdesign und KI – und über all das, was passiert, wenn diese drei Welten aufeinandertreffen.

[Mehr erfahren](https://de.goodbarber.com/blog/author/mathieu-poli/)

[![LinkedIn](https://portal.ww-cdn.com/portal_static/svg/base2021/linkedin.3ed8162e2a2b.svg)](https://www.linkedin.com/in/hellomathieup)[![X](https://portal.ww-cdn.com/portal_static/svg/base2021/x.820492c586dd.svg)](https://x.com/hellomathieup/)