---
title: "Testare il Custom Code GoodBarber con un utente connesso"
description: "Serve far comportare il proprio Custom Code di GoodBarber in modo diverso per un utente connesso — mostrare contenuti premium, salutare un membro per nome, nasc"
canonical_url: "https://it.goodbarber.com/blog/testare-il-custom-code-goodbarber-con-un-utente-connesso-a1052/"
lang: it
date: 2026-06-26
last_updated: 2026-07-17
---

# Testare il Custom Code GoodBarber con un utente connesso

[Indietro](/blog/make-it-r10/)

# Testare il Custom Code GoodBarber con un utente connesso

Scritto da [Mathieu Poli](https://it.goodbarber.com/blog/author/mathieu-poli/)  il Venerdì 26 Giugno 2026

## Serve far comportare il proprio Custom Code di GoodBarber in modo diverso per un utente connesso — mostrare contenuti premium, salutare un membro per nome, nascondere una sezione ai visitatori anonimi? Che tu abbia scritto quel codice di tuo pugno o lo abbia generato con l'AI Extension Builder, esso chiede all'App API chi è connesso tramite gb.user.getCurrent(). Ma l'anteprima del back-office non ha un login reale, quindi per le app Membership quella chiamata finisce sempre nel percorso di errore. Questa guida spiega come si comporta l'utente corrente nell'anteprima per ogni tipo di app e offre un metodo copia-incolla per testare l'app come membro connesso.

![](https://cmsphoto.ww-cdn.com/superstatic/81312/art/grande/97133650-67674234.jpg?v=1782463731.0364044)

Molto Custom Code ha bisogno di sapere **chi sta usando l'app in questo momento**: mostrare contenuti premium, salutare i membri per nome, nascondere una sezione ai visitatori anonimi, adattare un checkout. L'App API di GoodBarber fornisce l'utente corrente tramite `gb.user.getCurrent()`.

E il Custom Code non è più soltanto qualcosa che si scrive a mano. Con l'**[AI Extension Builder](https://it.goodbarber.com/blog/ai-extension-builder-crea-sezioni-con-l-ia-senza-programmare-a1003/)** di GoodBarber, descrivi in linguaggio naturale la sezione che desideri e l'assistente genera l'estensione al posto tuo — codice che si aggancia direttamente alla stessa App API di GoodBarber. Scritto a mano o generato dall'AI, chiama `gb.user.getCurrent()` allo stesso modo, e lo testi allo stesso modo. Quindi questa guida vale sia che tu abbia digitato il codice, sia che lo abbia richiesto con un prompt.

C'è però un dettaglio in cui ogni sviluppatore prima o poi si imbatte: **dentro l'anteprima del back-office non c'è alcun utente connesso.** L'anteprima è soltanto un rendering dell'app — non c'è una schermata di login, né una sessione, né nulla con cui autenticarsi.

Per la maggior parte dei tipi di app, GoodBarber risolve la cosa in modo trasparente, così testare "come utente connesso" funziona senza problemi. Per l'estensione **[Membership](https://it.goodbarber.com/blog/gli-abbonamenti-sono-arrivati-a759/)** non è così — ed è voluto. Questo articolo illustra come si comporta l'utente corrente nell'anteprima per ciascun tipo di app e fornisce un modo semplice, copia-incolla, per testare il caso più ostico: un **membro** connesso.

## Un breve ripasso: gb.user.getCurrent()

L'App API di GoodBarber permette al proprio Custom Code di chiedere "chi sta usando l'app in questo momento?" tramite un unico metodo:

gb.user.getCurrent( (user) => { // Un utente è connesso. // `user` è un oggetto GBUser — qui se ne leggono gli attributi. console.log(user.email); }, (error) => { // Nessun utente è connesso. console.log(`Response status: ${error.code}`); console.log(`Response message: ${error.message}`); } );

Accetta **due callback**: una di successo (richiamata con un oggetto `GBUser` quando qualcuno è connesso) e una di errore (richiamata quando non c'è nessun utente connesso). È basato su callback — **non** restituisce un valore né una Promise.

**L'oggetto *GBUser* cambia forma a seconda del tipo di app**

Il modello `GBUser` porta con sé una proprietà `api_version` che indica quale tipo di app lo ha prodotto:

| `api_version` | Tipo di app                                     |
| ------------- | ----------------------------------------------- |
| `1`           | App Content **+** estensione **Authentication** |
| `2`           | App **eCommerce**                               |
| `3`           | App Content **+** estensione **Membership**     |

L'elenco degli attributi dipende da quella versione. Per un'app **Membership** (`api_version: 3`), un `GBUser` si presenta così:

{ 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"] // 👈 il campo chiave per Membership }

L'array `access_levels` è ciò che rende speciale Membership: elenca i livelli di accesso di cui l'utente dispone in quel momento. È quasi sempre il valore su cui il proprio Custom Code prende decisioni ("questo utente ha `premium`? allora mostra il contenuto bonus").

In pratica, il codice legge `access_levels` per decidere cosa mostrare:

gb.user.getCurrent( (user) => { if (user.access_levels.includes("premium")) { console.log("Il membro ha premium — mostra il contenuto premium"); } else { console.log("Connesso, ma senza premium — mostra l'invito all'upgrade"); } }, (error) => { console.log("Nessun utente connesso — mostra l'invito al login"); } );

Vale la pena tenerlo a mente — è esattamente questo il codice che il mock qui sotto andrà ad alimentare.

## Come si comporta l'utente corrente nell'anteprima

L'anteprima nel back-office è una sandbox. Esegue il rendering dell'app, ma **non ha alcun meccanismo di login** — al suo interno non c'è modo di autenticare davvero un utente reale.

Per rendere comunque comodo lo sviluppo, GoodBarber **inietta un utente fittizio** per alcuni tipi di app, in modo che `getCurrent()` restituisca *qualcosa* su cui lavorare:

| Tipo di app                                  | Nell'anteprima, `getCurrent()`…                                                                                     |
| -------------------------------------------- | ------------------------------------------------------------------------------------------------------------------- |
| Add-on **Authentication** (`api_version: 1`) | ✅ Restituisce automaticamente un **utente fittizio** — la callback di successo viene richiamata.                    |
| App **eCommerce** (`api_version: 2`)         | ✅ Restituisce automaticamente un **cliente fittizio** — la callback di successo viene richiamata.                   |
| Estensione **Membership** (`api_version: 3`) | ❌ Non restituisce **nulla** — viene richiamata la callback di **errore** con `"There's no user logged in the app."` |

Quindi se l'app usa **Authentication** o **eCommerce**, è possibile testare subito la logica per utente connesso nell'anteprima — un utente fittizio viene fornito gratuitamente, senza alcuna configurazione.

Se invece l'app usa l'estensione **Membership**, le cose cambiano: **non viene iniettato alcun utente fittizio.** Se la callback di successo non viene mai richiamata nell'anteprima e si finisce sempre nel percorso di errore, è il comportamento previsto — semplicemente non c'è un utente corrente da restituire e, a differenza degli altri due tipi di app, nessuno viene simulato al posto vostro.

Il resto dell'articolo si concentra proprio sul caso Membership, perché è quello che richiede un po' di lavoro. Ci sono due modi per affrontarlo.

## Opzione 1 — Testare nell'app MyGoodBarber (condizioni reali)

Il modo più fedele per testare è eseguire l'app dentro l'app **MyGoodBarber** (disponibile su iOS e Android). Carica l'app reale, con il vero flusso di login e il vero backend. Ci si connette come membro effettivo e `getCurrent()` restituisce il `GBUser` reale con i veri `access_levels`.

Da usare quando si vuole validare *l'intero* flusso end-to-end prima della pubblicazione. È la cosa più vicina alla produzione.

Lo svantaggio: il ciclo di feedback è più lento. Non si può iterare su una modifica CSS o su un ramo condizionale alla stessa velocità dell'anteprima. È qui che entra in gioco l'Opzione 2.

## Opzione 2 — Simulare getCurrent() nell'anteprima

Per iterare rapidamente, si può **sostituire temporaneamente** `gb.user.getCurrent` con una versione propria che restituisce un membro fittizio a scelta. La logica reale resta identica — il proprio Custom Code continua a chiamare `gb.user.getCurrent(success, error)` come al solito. Si cambia soltanto *ciò che fa il metodo* durante i test.

**Passaggio 1 — Inserire il mock all'inizio del codice**

Aggiungere questo blocco proprio all'inizio del JavaScript del proprio Custom Code, prima di qualsiasi chiamata a `getCurrent()`:

// ⚠️ SOLO PER TEST IN ANTEPRIMA — rimuovere (o impostare a false) prima di pubblicare! 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"] // 👈 modificare per testare casi diversi }; successCallback(fakeUser); }; }
> 💡 `"premium"` è solo un esempio. Usare gli **identificatori dei livelli di accesso realmente configurati nella propria app** — altrimenti le condizioni non corrisponderanno a nulla.

Ci si potrebbe chiedere: il mio codice non potrebbe semplicemente rilevare l'anteprima e attivare il mock solo lì? Purtroppo no — non esiste alcun segnale affidabile esposto al Custom Code che dica "questa è l'anteprima" (`gb.platform()` restituisce `"web"` nell'anteprima, esattamente come una vera PWA in produzione) e, basandosi solo su `getCurrent`, l'anteprima è indistinguibile da un utente realmente disconnesso (entrambi finiscono nella callback di errore). Per questo si usa un flag da impostare **a mano**: è esplicito e non può attivarsi per sbaglio in produzione.

Tutto qui. D'ora in poi, ovunque nel proprio Custom Code si chiami:

gb.user.getCurrent(onUserFound, onNoUser);

…la callback `onUserFound` riceverà il membro fittizio qui sopra — esattamente come se fosse connesso un vero membro `premium`. **Non si cambia in alcun modo la logica di business**; si aggiunge soltanto il blocco mock in cima.

**Passaggio 2 — Testare i casi che contano**

Tutto il senso del codice Membership è reagire a utenti *diversi*. Basta modificare il mock per coprire ogni scenario:

**Un membro con abbonamento (ha livelli di accesso):**

access_levels: ["premium"]

**Un utente connesso senza abbonamento:**

access_levels: []

**Più livelli di accesso contemporaneamente:**

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

**Nessun utente connesso** — qui si simula il percorso di *errore* anziché quello di successo:

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

Alternando questi casi ci si assicura che il proprio Custom Code si comporti correttamente in ogni stato — non solo nel percorso ideale.

**Passaggio 3 (opzionale) — Simulare anche *gb.membership.getAccessLevels()***

Una parte del codice Membership legge i livelli di accesso tramite il metodo dedicato di Membership anziché dall'oggetto utente:

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

Se lo si usa, va simulato allo stesso modo:

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

## ⚠️ Prima di pubblicare: disattivare il mock

Questa è l'unica regola che non si può saltare. Il mock è una stampella per lo sviluppo — **non deve mai arrivare in produzione.** Se lo si pubblica, ogni utente dell'app verrà trattato come il membro fittizio `premium`, indipendentemente da ciò che ha effettivamente pagato.

Due abitudini sicure:

1. Tenere tutto dietro l'unico flag `PREVIEW_TESTING` e impostarlo a `false` prima di pubblicare.
2. Meglio ancora, **eliminare del tutto il blocco mock** una volta finiti i test.

Quando `PREVIEW_TESTING` è `false` (o il blocco è stato rimosso), `gb.user.getCurrent` torna a usare l'implementazione reale di GoodBarber e il proprio Custom Code lavora con i membri effettivamente connessi.

Pronti a provarci? Aprire la sezione **Custom Code** nel proprio back-office GoodBarber, incollare il blocco mock all'inizio del JavaScript e impostare gli `access_levels` per il caso che si vuole testare. Quando tutto funziona, impostare `PREVIEW_TESTING` a `false` (o eliminare il blocco) e pubblicare. Per il riferimento completo, consultare la [documentazione dell'App API](https://app.goodbarber.dev/v2/documentation/).

E se preferisci non scrivere l'estensione a mano, è proprio qui che entra in gioco l'**AI Extension Builder**: descrivi in linguaggio naturale la sezione che desideri e l'assistente genera l'estensione, la aggancia alle API native di GoodBarber e la mostra dal vivo nella tua app. È costruito sulla stessa App API — così la tecnica vista sopra è sempre a portata di mano, ogni volta che vuoi vedere in anteprima come si comporta la tua estensione per un membro connesso.

## Approfondimenti

- [`gb.user.getCurrent`](https://app.goodbarber.dev/v2/documentation/#tag/user-methods/operation/gb.user.getCurrent) — recupera l'utente attualmente connesso.
- [`GBUser`](https://app.goodbarber.dev/v2/documentation/#tag/user-models/operation/GBUser) — il modello utente e come cambiano i suoi attributi per ogni `api_version`.
- [`gb.membership.getAccessLevels`](https://app.goodbarber.dev/v2/documentation/#tag/membership-methods/operation/gb.membership.getAccessLevels) — legge direttamente i livelli di accesso (disponibile solo con l'add-on Memberships).
- [GoodBarber per gli sviluppatori: più libertà e strumenti per power user](https://it.goodbarber.com/blog/goodbarber-open-piu-liberta-per-gli-sviluppatori-e-gli-utenti-esperti-a912/) — cosa puoi costruire oltre l'editor no-code.

## Riepilogo

- Nell'anteprima del back-office **non esiste un login reale**.
- Per le app **Authentication** ed **eCommerce**, GoodBarber inietta automaticamente un utente fittizio, quindi testare come utente connesso funziona senza problemi.
- Per l'estensione **Membership**, **non viene fornito alcun utente fittizio** — `getCurrent()` finisce nella callback di errore.
- Per testare rapidamente nell'anteprima, **sovrascrivere temporaneamente `gb.user.getCurrent`** (e `gb.membership.getAccessLevels` se lo si usa) per restituire un membro fittizio con gli `access_levels` che si vogliono testare.
- Per una verifica reale, end-to-end, eseguire l'app dentro l'app **MyGoodBarber**.
- **Rimuovere sempre il mock prima di pubblicare.**

## FAQ

**Perché `gb.user.getCurrent()` restituisce un errore nell'anteprima per la mia app Membership?**

Perché l'anteprima del back-office non ha un meccanismo di login e, per le app Membership (`api_version: 3`), GoodBarber non inietta un utente fittizio. Senza nessuno connesso, il metodo richiama la callback di errore con `"There's no user logged in the app."` — è un comportamento previsto, non un bug.

**Perché lo stesso codice funziona nell'anteprima per un'app Authentication o eCommerce?**

Per le app Authentication (`api_version: 1`) ed eCommerce (`api_version: 2`), GoodBarber inietta automaticamente un utente fittizio (o un cliente fittizio) nell'anteprima, quindi la callback di successo viene richiamata senza alcuna configurazione.

**Come posso testare un membro connesso senza pubblicare l'app?**

O si esegue l'app dentro l'app MyGoodBarber (iOS/Android) per testarla in condizioni reali, oppure si sovrascrive temporaneamente `gb.user.getCurrent` nel proprio Custom Code per restituire un membro fittizio con gli `access_levels` che si vogliono testare.

**Cos'è `access_levels` nell'oggetto `GBUser`?**

È un array dei livelli di accesso di cui un utente Membership dispone in quel momento (per esempio `["premium"]`). Il proprio Custom Code di solito vi si basa per decidere quali contenuti mostrare. Un array vuoto (`[]`) indica un utente connesso senza alcun abbonamento attivo.

**`gb.user.getCurrent()` restituisce una Promise?**

No. È basato su callback: si passa una callback di successo e una di errore. Non restituisce un valore, quindi non si può usare `await`.

**Cosa succede se dimentico di rimuovere il mock prima di pubblicare?**

Ogni utente dell'app verrà trattato come il membro fittizio scritto a codice fisso — otterrebbero tutti, ad esempio, l'accesso `premium` indipendentemente da ciò che hanno effettivamente pagato. Impostare sempre `PREVIEW_TESTING` a `false` o eliminare il blocco mock prima di pubblicare.

- [#ComeFare](https://it.goodbarber.com/blog/tags/comefare)

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

Informazioni sull'autore[Mathieu Poli](https://it.goodbarber.com/blog/author/mathieu-poli/)Head of Frontend Engineering

Sono Head of Frontend Engineering presso GoodBarber.

Supervisiono i team che progettano i motori di rendering al cuore della nostra piattaforma no-code: sono loro a dare vita ai progetti dei nostri utenti e a trasformarli in app native, fluide e curate. Tutto ciò che si vede e si tocca sullo schermo passa dalle loro mani.
Pioniere del no-code mobile, appassionato di architettura software e di design di prodotto, insegno anche in università e scuole private.

Qui scrivo di ingegneria frontend, design di prodotto e IA — e di tutto ciò che accade quando questi tre mondi si incontrano.

[Scopri di più](https://it.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/)