Chiavi

FortressFlag ha due tipi di chiavi, e sono opposte di proposito. Sapere quale è quale — e trattare ciascuna di conseguenza — è quasi tutto quello che c’è da sapere.

Chiavi client: `ffc_` — pubbliche per progettazione

Una chiave client autentica il piano client: le tue app iOS, Android e web. Viaggia dentro ogni copia della tua app, e chiunque abbia il tuo binario o il sorgente della tua pagina può leggerla. Il design lo dà per scontato. Una chiave client:

è in sola lettura, con ambito un progetto e un ambiente
può recuperare solo i valori valutati di un singolo dispositivo — mai le tue regole, mai i dati di un altro dispositivo, mai nulla dell’API di gestione
è soggetta a rate limit per chiave e per dispositivo

Quindi mettila nella configurazione della tua app a cuor leggero. Ciò che qualcuno impara possedendo la tua chiave client sono le chiavi dei tuoi flag per un ambiente — che poteva già leggere dal binario in cui la chiave viaggiava. Il prefisso ffc_ esiste perché gli scanner di segreti possano riconoscerla come chiave client e non svegliare nessuno.

Chiavi server: `ffs_` — un segreto vero e proprio

Una chiave server autentica il piano server: il tuo backend che scarica il ruleset completo — regole di targeting incluse — per la valutazione locale. Trattala esattamente come la password di un database:

conservala in un secret manager o in una variabile d’ambiente
mai nel codice lato client, mai in un repository, mai in un log
il prefisso ffs_ è lì perché uno scanner di leak la classifichi come un segreto vero che deve svegliare qualcuno — l’esatto opposto di ffc_, ed è per questo che le due non condividono il prefisso

Anche una chiave server ha come ambito un progetto e un ambiente, è in sola lettura e non può raggiungere l’API di gestione. Ma il suo raggio di danno in caso di leak sono le tue regole di targeting, non solo le chiavi dei tuoi flag — da qui il trattamento diverso.

Generare, mostrare una sola volta, revocare

Le chiavi si gestiscono dalla schermata Chiavi SDK di ogni progetto (Admin e Owner generano e revocano; i Developer possono vedere l’elenco):

Generare crea una chiave legata a un progetto + ambiente. La chiave completa viene mostrata esattamente una volta, al momento della generazione — copiala allora, perché dopo l’elenco mostra solo quanto basta per identificarla. Non esiste «mostra di nuovo la chiave»: una chiave che può essere rivisualizzata è una chiave conservata in una forma che può essere rubata.
Revocare ha effetto al prossimo utilizzo della chiave — nessun rilascio dell’app, nessun deploy. Ed è sicuro farlo sotto pressione: gli SDK che detengono una chiave revocata ricadono sulla loro cache invece di rompersi.

Rotazione

Più chiavi attive per ambiente sono legittime, ed è questa la ricetta della rotazione: genera la nuova chiave, distribuiscila alle tue app o ai tuoi server, poi revoca quella vecchia. Nessun downtime, nessun buco nel servire i flag, e la finestra in cui entrambe le chiavi funzionano la controlli tu.

Prossimi passi

Come i flag raggiungono la tua app — i due piani che queste chiavi sbloccano
Ambienti e progetti — l’ambito a cui una chiave è legata
Ruoli e sicurezza — chi può generare e revocare