Auth - Autenticazione e Gestione Utenti di Supabase

Auth è un server di gestione utenti e autenticazione scritto in Go che alimenta le funzionalità di Supabase, come:

• Emissione di JWT
• Row Level Security con PostgREST
• Gestione utenti
• Accesso con email, password, magic link, numero di telefono
• Accesso con provider esterni (Google, Apple, Facebook, Discord, ...)

È originariamente basato sull'eccellente codebase GoTrue di Netlify, tuttavia entrambi si sono discostati in modo significativo per caratteristiche e funzionalità.

Se desideri contribuire al progetto, fa riferimento alla guida al contributo.

Table of Contents

• Quick Start
• Running in Production
• Configuration
• Endpoints

Avvio Rapido

Crea un file .env per memorizzare le tue variabili d'ambiente personalizzate. Vedi example.env

1. Avvia il database Postgres locale in un container Postgres: docker-compose -f docker-compose-dev.yml up postgres
2. Compila il binario auth: make build . Dovresti vedere un output simile a questo:```bash go build -ldflags "-X github.com/supabase/auth/cmd.Version=git rev-parse HEAD" GOOS=linux GOARCH=arm64 go build -ldflags "-X github.com/supabase/auth/cmd.Version=git rev-parse HEAD" -o gotrue-arm64

3. Esegui il binario auth: `./auth`

### Se hai Docker installato

Crea un file `.env.docker` per memorizzare le tue variabili d'ambiente personalizzate. Vedi [`example.docker.env`](https://github.com/supabase/auth/blob/master/example.docker.env)

1. `make build`
2. `make dev`
3. `docker ps` dovrebbe mostrare due container Docker (`auth-auth-1` e `auth-postgres-1`)
4. Tutto qui! Visita l'[endpoint di health check](http://localhost:9999/health) per confermare che auth sia in esecuzione.

## Esecuzione in produzione

Eseguire un server di autenticazione in produzione non è un'impresa facile. Ti
consigliamo di utilizzare [Supabase Auth](https://supabase.com/auth), che riceve regolari
aggiornamenti di sicurezza.

In caso contrario, assicurati di predisporre un processo per aggiornare tempestivamente all'
ultima versione. Puoi farlo seguendo questo repository, in particolare le
sezioni [Releases](https://github.com/supabase/auth/releases) e [Security
Advisories](https://github.com/supabase/auth/security/advisories).

### Retrocompatibilità

Auth utilizza lo schema [Semantic Versioning](https://semver.org). Ecco alcuni
ulteriori chiarimenti sulle garanzie di retrocompatibilità:

**Compatibilità API Go**

Auth non è pensato per essere usato come libreria Go. Non ci sono garanzie sulla
retrocompatibilità API quando usato in questo modo, a prescindere da quale
numero di versione cambi.

**Patch**

Le modifiche alla versione patch garantiscono la retrocompatibilità con:

- Oggetti del database (tabelle, colonne, indici, funzioni).
- API REST
- Struttura JWT
- Configurazione

Esempi garantiti:

- Una colonna non cambierà il suo tipo.
- Una tabella non cambierà la sua chiave primaria.
- Un indice non verrà rimosso.
- Un vincolo di unicità non verrà rimosso.
- Un'API REST non verrà rimossa.
- I parametri delle API REST funzioneranno in modo equivalente a prima (o meglio, se un bug
  è stato corretto).
- La configurazione non cambierà.

Esempi non garantiti:

- Una tabella potrebbe aggiungere nuove colonne.
- Le colonne in una tabella potrebbero essere riordinate.
- I vincoli non univoci potrebbero essere rimossi (controlli a livello di database, null, valori
  predefiniti).
- JWT potrebbe aggiungere nuove proprietà.

**Minor**

Le modifiche alla versione minor garantiscono la retrocompatibilità con:

- API REST
- Struttura JWT
- Configurazione

Eccezioni a queste garanzie saranno ammesse solo quando verranno trovati seri problemi
di sicurezza che non possono essere risolti in nessun altro modo.

Esempi garantiti:

- Le API esistenti potrebbero essere deprecate ma continueranno a funzionare per le prossime poche
  versioni minor.
- Le modifiche alla configurazione potrebbero diventare deprecate ma continueranno a funzionare per
  le prossime poche versioni minor.
- I JWT già emessi saranno accettati, ma i nuovi JWT potrebbero avere una
  struttura diversa (ma di solito simile).

Esempi non garantiti:

- Rimozione dei campi JWT dopo un avviso di deprecazione.
- Rimozione di alcune API dopo un avviso di deprecazione.
- Rimozione dell'accesso con provider esterni dopo un avviso di deprecazione.
- Eliminazione, troncamento, modifiche significative dello schema di tabelle, indici, viste,
  funzioni.

Puntiamo a fornire un avviso di deprecazione nei log di esecuzione per almeno due
versioni major o due settimane se vengono pubblicate più release. La compatibilità sarà
garantita finché l'avviso è attivo.

**Major**

Le modifiche alla versione major non garantiscono alcuna retrocompatibilità con
le versioni precedenti.

### Funzionalità ereditate

Alcune funzionalità ereditate dal codebase di Netlify non sono supportate da
Supabase e potrebbero essere rimosse senza preavviso in futuro. Questa è una
lista completa di tali funzionalità:

1. Multi-tenancy tramite la tabella `instances`, cioè il parametro di configurazione
   `GOTRUE_MULTI_INSTANCE_MODE`.
2. Utente di sistema (utente UUID zero).
3. Super admin tramite la colonna `is_super_admin`.
4. Informazioni di gruppo nei JWT tramite `GOTRUE_JWT_ADMIN_GROUP_NAME` e altri
   campi di configurazione.
5. Firma JWT. Supabase Auth supporta chiavi asimmetriche (RS256 di default;
   ECC/Ed25519 opzionali). HS256 è ancora supportato per compatibilità, ma
   migrare verso chiavi asimmetriche è consigliato per una validazione e una
   rotazione più semplici. Le future deprecazioni saranno annunciate nel changelog. Vedi la
   [guida JWT Signing Keys](https://supabase.com/docs/guides/auth/signing-keys) e
   [la guida JWTs](https://supabase.com/docs/guides/auth/jwts) per i dettagli.

Nota che questa non è una lista esaustiva e potrebbe cambiare.

### Buone pratiche per il self-hosting

Queste sono alcune buone pratiche da seguire quando si fa self-hosting per garantire la
retrocompatibilità con Auth:

1. Non modificare lo schema gestito da Auth. Puoi vedere tutte le
   migrazioni nella directory `migrations`.
2. Non fare affidamento sullo schema e sulla struttura dei dati nel database. Usa sempre
   le API di Auth e i JWT per dedurre informazioni sugli utenti.
3. Esegui sempre Auth dietro un proxy in grado di gestire TLS, come un load balancer, CDN,
   nginx o altro software simile.

## Configurazione

Puoi configurare Auth usando un file di configurazione chiamato `.env`,
variabili d'ambiente, o una combinazione di entrambi. Le variabili d'ambiente hanno il prefisso `GOTRUE_` e avranno sempre precedenza sui valori forniti tramite file.

### Livello principale```properties
GOTRUE_SITE_URL=https://example.netlify.com/

SITE_URL - string obbligatorio

L'URL di base in cui si trova il tuo sito. Attualmente utilizzato in combinazione con altre impostazioni per costruire gli URL usati nelle email. Qualsiasi URI che condivide un host con SITE_URL è un valore consentito per i parametri redirect_to (vedi /authorize ecc.).

URI_ALLOW_LIST - string