---
title: "GoodBarber Custom Code testen met een ingelogde gebruiker"
description: "Moet je GoodBarber Custom Code zich anders gedragen voor een ingelogde gebruiker — premium content tonen, een member bij naam begroeten, een sectie verbergen vo"
canonical_url: "https://nl.goodbarber.com/blog/goodbarber-custom-code-testen-met-een-ingelogde-gebruiker-a1386/"
lang: nl
date: 2026-06-26
last_updated: 2026-07-17
---

# GoodBarber Custom Code testen met een ingelogde gebruiker

[Terug](/blog/maak-het-waar-r13/)

# GoodBarber Custom Code testen met een ingelogde gebruiker

Written by [Mathieu Poli](https://nl.goodbarber.com/blog/author/mathieu-poli/)  on Vrijdag 26 Juni 2026

## Moet je GoodBarber Custom Code zich anders gedragen voor een ingelogde gebruiker — premium content tonen, een member bij naam begroeten, een sectie verbergen voor anonieme bezoekers? Of je die code nu zelf hebt geschreven of hem hebt gegenereerd met de AI Extension Builder, hij vraagt de App API wie er is ingelogd via gb.user.getCurrent(). Maar de preview in de back office heeft geen echte login, dus bij Membership-apps komt die aanroep altijd in het error-pad terecht. Deze gids legt uit hoe de huidige gebruiker zich in de preview gedraagt voor elk app-type, en geeft je een kant-en-klare manier om als ingelogde member te testen.

![](https://cmsphoto.ww-cdn.com/superstatic/2962774/art/grande/97133655-67674263.jpg?v=1782463737.0364392)

Veel Custom Code moet weten **wie de app op dit moment gebruikt**: premium content tonen, members bij naam begroeten, een sectie verbergen voor anonieme bezoekers, een checkout aanpassen. De GoodBarber App API geeft je de huidige gebruiker via `gb.user.getCurrent()`.

En Custom Code is allang niet meer alleen iets wat je met de hand schrijft. Met de **[AI Extension Builder](https://nl.goodbarber.com/blog/ai-extension-builder-maak-secties-met-ai-zonder-code-a1338/)** van GoodBarber beschrijf je de sectie die je wilt in gewone taal en genereert de assistent de extensie voor je — code die rechtstreeks aansluit op diezelfde GoodBarber App API. Met de hand geschreven of door AI gegenereerd, ze roept `gb.user.getCurrent()` op dezelfde manier aan, en je test ze op dezelfde manier. Deze gids geldt dus of je de code nu zelf hebt getypt of erom hebt gevraagd.

Maar er is een addertje onder het gras waar elke developer vroeg of laat tegenaan loopt: **binnen de preview van de back office is er geen ingelogde gebruiker.** De preview is gewoon een weergave van je app — er is geen loginscherm, geen sessie, niets om tegen te authenticeren.

Voor de meeste app-types lost GoodBarber dit stilletjes voor je op, zodat testen "als ingelogde gebruiker" gewoon werkt. Voor de **[Membership](https://nl.goodbarber.com/blog/de-lidmaatschap-is-er-a1078/)**-extensie is dat niet zo — en dat is met opzet. Dit artikel loopt door hoe de huidige gebruiker zich in de preview gedraagt per app-type, en geeft je een eenvoudige, kant-en-klare manier om het lastigste geval te testen: een ingelogde **member**.

## Even opfrissen: gb.user.getCurrent()

Met de GoodBarber App API kan je Custom Code vragen "wie gebruikt de app op dit moment?" via één methode:

gb.user.getCurrent( (user) => { // Er is een gebruiker ingelogd. // `user` is een GBUser-object — lees hier de attributen uit. console.log(user.email); }, (error) => { // Er is geen gebruiker ingelogd. console.log(`Response status: ${error.code}`); console.log(`Response message: ${error.message}`); } );

De methode neemt **twee callbacks**: een success-callback (aangeroepen met een `GBUser`-object wanneer er iemand is ingelogd) en een error-callback (aangeroepen wanneer er niemand is ingelogd). De methode werkt op basis van callbacks — ze geeft **geen** waarde of Promise terug.

**Het *GBUser*-object verandert van vorm per app-type**

Het `GBUser`-model bevat een `api_version`-property die je vertelt welk soort app het heeft geproduceerd:

| `api_version` | App-type                                  |
| ------------- | ----------------------------------------- |
| `1`           | Content-app **+ Authentication**-extensie |
| `2`           | **eCommerce**-app                         |
| `3`           | Content-app **+ Membership**-extensie     |

De lijst met attributen hangt af van die versie. Voor een **Membership**-app (`api_version: 3`) ziet een `GBUser` er zo uit:

{ 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"] // 👈 het sleutelveld voor Membership }

De `access_levels`-array maakt Membership bijzonder: ze geeft de toegangsniveaus weer die de gebruiker op dat moment heeft. Daar baseert je Custom Code bijna altijd zijn vertakkingen op ("heeft deze gebruiker `premium`? toon dan de bonuscontent").

In de praktijk leest je code `access_levels` uit om te beslissen wat er getoond wordt:

gb.user.getCurrent( (user) => { if (user.access_levels.includes("premium")) { console.log("Member heeft premium — toon de premium content"); } else { console.log("Ingelogd, maar geen premium — toon de upgrade-prompt"); } }, (error) => { console.log("Niemand ingelogd — toon de login-prompt"); } );

Onthoud dit goed — het is precies deze code die de mock hieronder gaat voeden.

## Hoe de huidige gebruiker zich in de preview gedraagt

De preview in de back office is een sandbox. Hij rendert je app, maar heeft **geen loginmechanisme** — er is geen manier om er een echte gebruiker in te authenticeren.

Om het ontwikkelen toch comfortabel te houden, **injecteert GoodBarber een neppe gebruiker** voor sommige app-types, zodat `getCurrent()` *iets* teruggeeft waarmee je kunt werken:

| App-type                                     | In de preview doet `getCurrent()`…                                                                           |
| -------------------------------------------- | ------------------------------------------------------------------------------------------------------------ |
| **Authentication**-add-on (`api_version: 1`) | ✅ Geeft automatisch een **neppe gebruiker** terug — je success-callback wordt aangeroepen.                   |
| **eCommerce**-app (`api_version: 2`)         | ✅ Geeft automatisch een **neppe klant** terug — je success-callback wordt aangeroepen.                       |
| **Membership**-extensie (`api_version: 3`)   | ❌ Geeft **niets** terug — je **error**-callback wordt aangeroepen met `"There's no user logged in the app."` |

Gebruikt je app dus **Authentication** of **eCommerce**, dan kun je je ingelogde logica meteen in de preview testen — een neppe gebruiker wordt je gratis aangereikt, zonder enige setup.

Gebruikt je app de **Membership**-extensie, dan is het anders: **er wordt geen neppe gebruiker geïnjecteerd.** Als je success-callback in de preview nooit afgaat en je steeds in het error-pad belandt, dan is dat verwacht gedrag — er is simpelweg geen huidige gebruiker om terug te geven, en anders dan bij de andere twee app-types wordt er voor jou geen neppe aangemaakt.

De rest van dit artikel richt zich op dat Membership-geval, want dat is het geval dat wat werk vereist. Je kunt het op twee manieren aanpakken.

## Optie 1 — Testen in de MyGoodBarber-app (echte omstandigheden)

De meest getrouwe manier om te testen is je app draaien binnen de **MyGoodBarber**-app (beschikbaar op iOS en Android). Die laadt je echte app, met de echte loginflow en de echte backend. Je logt in als een echte member, en `getCurrent()` geeft je echte `GBUser` met je echte `access_levels` terug.

Gebruik dit wanneer je de *hele* flow van begin tot eind wilt valideren voordat je publiceert. Het komt het dichtst bij productie.

Het nadeel: het is een tragere feedbackloop. Je kunt niet zo snel itereren op een CSS-aanpassing of een conditionele vertakking als in de preview. Daar komt Optie 2 om de hoek kijken.

## Optie 2 — getCurrent() mocken in de preview

Voor snelle iteratie kun je `gb.user.getCurrent` **tijdelijk vervangen** door je eigen versie die een neppe member van je keuze teruggeeft. Je echte logica blijft precies hetzelfde — je Custom Code roept `gb.user.getCurrent(success, error)` nog steeds gewoon aan. Je wisselt alleen *wat de methode doet* om tijdens het testen.

**Stap 1 — Plaats de mock bovenaan je code**

Voeg dit blok helemaal aan het begin van de JavaScript van je Custom Code toe, vóór elke aanroep van `getCurrent()`:

// ⚠️ ALLEEN VOOR PREVIEW-TESTS — verwijderen (of op false zetten) voordat je publiceert! 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"] // 👈 pas dit aan om verschillende gevallen te testen }; successCallback(fakeUser); }; }
> 💡 `"premium"` is maar een voorbeeld. Gebruik de **echte access level-identifiers die in jouw app zijn geconfigureerd** — anders matchen je condities met niets.

Misschien vraag je je af: kan mijn code de preview niet gewoon detecteren en alleen daar mocken? Helaas niet — er is geen betrouwbaar signaal beschikbaar in je Custom Code dat zegt "dit is de preview" (`gb.platform()` geeft `"web"` terug in de preview, precies zoals een echte PWA in productie), en op basis van `getCurrent` alleen is de preview niet te onderscheiden van een echt uitgelogde gebruiker (beide belanden in de error-callback). Daarom gebruiken we een flag die je **met de hand** omzet: dat is expliciet, en kan niet per ongeluk in productie worden geactiveerd.

Dat is alles. Vanaf nu krijgt je `onUserFound`-callback overal in je Custom Code waar je het volgende aanroept:

gb.user.getCurrent(onUserFound, onNoUser);

…de neppe member van hierboven binnen — precies alsof er een echte `premium`-member was ingelogd. **Je verandert helemaal niets aan je businesslogica**; je hebt er alleen het mock-blok bovenop gezet.

**Stap 2 — Test de gevallen die ertoe doen**

De hele bedoeling van Membership-code is reageren op *verschillende* gebruikers. Pas gewoon de mock aan om elk scenario af te dekken:

**Een geabonneerde member (heeft access levels):**

access_levels: ["premium"]

**Een ingelogde gebruiker zonder abonnement:**

access_levels: []

**Meerdere access levels tegelijk:**

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

**Helemaal niemand ingelogd** — hier mock je het *error*-pad in plaats van het success-pad:

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

Wissel tussen deze gevallen om je ervan te verzekeren dat je Custom Code zich in elke staat correct gedraagt — niet alleen in het ideale geval.

**Stap 3 (optioneel) — Mock ook *gb.membership.getAccessLevels()***

Sommige Membership-code leest access levels uit via de speciale Membership-methode in plaats van via het user-object:

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

Als je die gebruikt, mock hem dan op dezelfde manier:

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

## ⚠️ Voordat je publiceert: zet de mock uit

Dit is de ene regel die je niet mag overslaan. De mock is een hulpmiddel tijdens de ontwikkeling — **hij mag nooit in productie belanden.** Als je hem uitrolt, wordt elke gebruiker van de app behandeld als jouw neppe `premium`-member, ongeacht waar ze daadwerkelijk voor betaald hebben.

Twee veilige gewoontes:

1. Houd alles achter de ene `PREVIEW_TESTING`-flag en zet die op `false` voordat je publiceert.
2. Beter nog: **verwijder het mock-blok helemaal** zodra je klaar bent met testen.

Wanneer `PREVIEW_TESTING` op `false` staat (of het blok weg is), valt `gb.user.getCurrent` terug op de echte implementatie van GoodBarber, en werkt je Custom Code tegen echte ingelogde members.

Klaar om het te proberen? Open de sectie **Custom Code** in je GoodBarber back office, plak het mock-blok bovenaan je JavaScript en stel de `access_levels` in voor het geval dat je wilt testen. Als alles zich gedraagt zoals het hoort, zet je `PREVIEW_TESTING` op `false` (of verwijder je het blok) en publiceer je. Voor de volledige referentie, zie de [App API-documentatie](https://app.goodbarber.dev/v2/documentation/).

En schrijf je de extensie liever niet met de hand, dan komt de **AI Extension Builder** precies daarvoor van pas: beschrijf de sectie die je wilt in gewone taal en hij genereert de extensie, sluit ze aan op de eigen API's van GoodBarber en rendert ze live in je app. Hij bouwt voort op dezelfde App API — dus de techniek hierboven ligt zo voor het grijpen wanneer je wilt previewen hoe je extensie zich gedraagt voor een ingelogde member.

## Verder lezen

- [`gb.user.getCurrent`](https://app.goodbarber.dev/v2/documentation/#tag/user-methods/operation/gb.user.getCurrent) — de huidige ingelogde gebruiker ophalen.
- [`GBUser`](https://app.goodbarber.dev/v2/documentation/#tag/user-models/operation/GBUser) — het user-model en hoe zijn attributen per `api_version` verschillen.
- [`gb.membership.getAccessLevels`](https://app.goodbarber.dev/v2/documentation/#tag/membership-methods/operation/gb.membership.getAccessLevels) — access levels rechtstreeks uitlezen (alleen beschikbaar met de Memberships-add-on).
- [GoodBarber voor developers: meer vrijheid en tools voor power-users](https://nl.goodbarber.com/blog/goodbarber-open-meer-vrijheid-voor-ontwikkelaars-en-deskundige-gebruikers-a1233/) — wat je kunt bouwen voorbij de no-code editor.

## Samenvatting

- In de preview van de back office is er **geen echte login**.
- Voor **Authentication**- en **eCommerce**-apps injecteert GoodBarber automatisch een neppe gebruiker, dus testen als ingelogde gebruiker werkt gewoon.
- Voor de **Membership**-extensie wordt **geen neppe gebruiker aangeleverd** — `getCurrent()` belandt in de error-callback.
- Om snel te testen in de preview, **overschrijf je tijdelijk `gb.user.getCurrent`** (en `gb.membership.getAccessLevels` als je die gebruikt) zodat ze een neppe member teruggeven met de `access_levels` die je wilt testen.
- Voor een echte controle van begin tot eind draai je je app binnen de **MyGoodBarber**-app.
- **Verwijder de mock altijd voordat je publiceert.**

## FAQ

**Waarom geeft `gb.user.getCurrent()` een error terug in de preview voor mijn Membership-app?**

Omdat de preview in de back office geen loginmechanisme heeft, en GoodBarber voor Membership-apps (`api_version: 3`) geen neppe gebruiker injecteert. Met niemand ingelogd roept de methode je error-callback aan met `"There's no user logged in the app."` — dit is verwacht gedrag, geen bug.

**Waarom werkt dezelfde code wél in de preview voor een Authentication- of eCommerce-app?**

Voor Authentication- (`api_version: 1`) en eCommerce-apps (`api_version: 2`) injecteert GoodBarber in de preview automatisch een neppe gebruiker (of neppe klant), zodat je success-callback afgaat zonder enige setup.

**Hoe test ik een ingelogde member zonder mijn app te publiceren?**

Draai je app binnen de MyGoodBarber-app (iOS/Android) om onder echte omstandigheden te testen, of overschrijf tijdelijk `gb.user.getCurrent` in je Custom Code zodat die een neppe member teruggeeft met de `access_levels` die je wilt testen.

**Wat is `access_levels` in het `GBUser`-object?**

Het is een array van de toegangsniveaus die een Membership-gebruiker op dat moment heeft (bijvoorbeeld `["premium"]`). Je Custom Code baseert zijn vertakkingen daar doorgaans op om te beslissen welke content er wordt getoond. Een lege array (`[]`) betekent een ingelogde gebruiker zonder actief abonnement.

**Geeft `gb.user.getCurrent()` een Promise terug?**

Nee. De methode werkt op basis van callbacks: je geeft een success-callback en een error-callback mee. Ze geeft geen waarde terug, dus je kunt er geen `await` op gebruiken.

**Wat gebeurt er als ik vergeet de mock te verwijderen voordat ik publiceer?**

Elke gebruiker van je app wordt behandeld als de neppe member die je hard hebt ingecodeerd — ze zouden allemaal bijvoorbeeld `premium`-toegang krijgen, ongeacht waar ze daadwerkelijk voor betaald hebben. Zet `PREVIEW_TESTING` altijd op `false` of verwijder het mock-blok voordat je publiceert.

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

Over de auteur[Mathieu Poli](https://nl.goodbarber.com/blog/author/mathieu-poli/)Head of Frontend Engineering

Ik ben Head of Frontend Engineering bij GoodBarber.

Ik geef leiding aan de teams die de rendering-engines bouwen die de kern vormen van ons no-codeplatform: zij zijn het die de projecten van onze gebruikers tot leven brengen en omzetten in native apps — vloeiend en verzorgd. Alles wat je op het scherm ziet en gebruikt, gaat door hun handen.
Als pionier van mobiele no-code, gepassioneerd door softwarearchitectuur en productdesign, geef ik daarnaast les aan universiteiten en particuliere hogescholen.

Hier schrijf ik over frontend engineering, productdesign en AI — en over alles wat er gebeurt wanneer die drie werelden samenkomen.

[Lees meer](https://nl.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/)