GoodBarber Custom Code testen met een ingelogde gebruiker

Written by 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.

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 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-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.getCurrenttijdelijk 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:

Houd alles achter de ene PREVIEW_TESTING-flag en zet die op false voordat je publiceert.
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.

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 — de huidige ingelogde gebruiker ophalen.
GBUser — het user-model en hoe zijn attributen per api_version verschillen.
gb.membership.getAccessLevels — access levels rechtstreeks uitlezen (alleen beschikbaar met de Memberships-add-on).
GoodBarber voor developers: meer vrijheid en tools voor power-users — 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.