Esegui l'upgrade all'SDK 0.6 e alle nuove regole delle funzioni

Installa la nuova versione:

npm install @aurabase/aurabase-js@0.6.0

La versione presenta una modifica alla sicurezza e diverse correzioni al modo in cui vengono segnalati errori e risposte. La modifica della sicurezza è anche nelle funzioni servizio: si applica al tuo progetto non appena il servizio viene aggiornato, qualunque sia la versione dell'SDK che utilizzi.

Le chiamate di gestione ora richiedono una chiave service_role

functions.list(), get(), listJobs(), getJob(), enqueueJob(), listCronJobs(), createCronJob() e deleteCronJob() restituiscono 403 a una chiave pubblica o a un utente connesso. Prima, list() e get() restituivano il codice sorgente e le variabili di ogni funzione a chiunque possedesse la chiave pubblica. Vedi il modello di sicurezza.

const { data } = await aura.functions.list() // ha funzionato con la chiave pubblica

// server/api/funzioni.ts
const admin = createClient(process.env.AURA_URL!, process.env.AURA_SERVICE_ROLE_KEY!)
export const GET = async () => Response.json((await admin.functions.list()).data?.map((f) => f.name))

Restituisci solo ciò di cui ha bisogno il tuo front-end (nomi, ad esempio), mai l'intera definizione.

Un corpo che non può essere JSON viene rifiutato

invoke(name, { body: new Blob(…) }), e lo stesso con ArrayBuffer, array digitati, FormData, URLSearchParams o ReadableStream, ora restituisce il codice di errore invalid_body. Prima, la funzione riceveva {} e non veniva segnalato alcun errore. Codifica i dati binari (base64) o caricali su Storage e invia il relativo percorso.

Il 502, 503 o 504 di una funzione è un FunctionsHttpError

Prima, questi stati erano sempre classificati come FunctionsRelayError, anche quando il codice li restituiva. Ora FunctionsRelayError significa che la piattaforma non è riuscita. Se hai riprovato su FunctionsRelayError, controlla che la logica dei tentativi corrisponda ancora: vedi Errori, timeout e tentativi di .

FunctionDef è più preciso

env_vars è Record<string, string> (era Record<string, unknown>) e viene aggiunto permissions. Il codice che legge questi campi continua a funzionare; il codice che assegnava valori di un altro tipo non viene più compilato.

Nuove esportazioni: FunctionsHttpError, FunctionsRelayError, isRelayStatus e FunctionsResponseType provengono da @aurabase/aurabase-js così come da @aurabase/functions. Se li hai importati da @aurabase/functions, continua a funzionare; con pnpm non hai più bisogno di quel pacchetto come dipendenza diretta.

In @aurabase/auth, il tipo di email nel risultato di getClaims() è ora string | null, ovvero ciò che il servizio restituisce per un utente senza un indirizzo di posta elettronica.

CLI. aura functions deploy non cancella più i segreti di una funzione già esistente. aura functions invoke --data rifiuta JSON non valido invece di inviare {}. aura functions download funziona per le funzioni Deno. aura functions serve ascolta sulla porta che annuncia. aura studio apre Studio sulla porta 3000.

Se il tuo progetto veniva eseguito su una versione del servizio precedente a questo cambiamento, qualsiasi detentore della tua chiave pubblica potrebbe leggere il codice e le variabili delle tue funzioni. Supponiamo che siano stati letti:

1. Elenca le tue funzioni con una chiave service_role e apri le variabili di ciascuna.
2. Ruota ogni segreto che contengono: chiavi di pagamento, segreti webhook, token di terze parti.
3. Rimuovi i segreti scritti direttamente in index.ts e spostali nelle variabili.
4. Controlla i lavori e le regole di avviso del progetto per le voci che non hai creato.

• Cerca il tuo codice per functions.list(, functions.get(, listJobs(, getJob(, enqueueJob(, createCronJob(, deleteCronJob( e listCronJobs( nel codice eseguito in un browser o con una chiave pubblica.
• Cerca valori body: che non siano semplici JSON.
• Controllare la logica dei tentativi che dipende da FunctionsRelayError.
• Ruota i segreti come descritto sopra.
• Aggiorna la CLI.