Che cosa sono i permessi di classe (CLP)?

Un permesso di classe è una regola sullo schema di una classe che controlla quali utenti o ruoli possono eseguire ciascuna operazione su quella classe. È la barriera più esterna della sicurezza dello strato dei dati: prima di qualsiasi controllo riga per riga, è la classe stessa a decidere se chi chiama possa fare find, create, update o delete qui – una regola, tutta la tabella, verificata per prima.

Punti chiave

La barriera della classe, dichiarata e percepita

Un CLP è configurazione dello schema – qui nella forma del payload REST che blocca una classe Config in lettura pubblica e scrittura riservata al server:

PUT /schemas/Config
{
  "classLevelPermissions": {
    "find":   { "*": true },              // chiunque può interrogare
    "get":    { "*": true },
    "create": {},                         // nessuno dal lato client
    "update": { "role:admin": true },     // solo gli admin
    "delete": {},
    "addField": {}                        // schema congelato
  }
}

Quello che i client sperimentano è la barriera che fa il suo lavoro – le letture passano, le scritture muoiono al confine della classe prima che un solo dato venga toccato:

// JavaScript / Node.js — Back4app JS SDK
// The class gate in action: Config is read-only for clients (CLP),
// so reads succeed and writes never reach the data
const config = await new Parse.Query('Config').first(); // ✓ public read

const c = new Parse.Object('Config');
c.set('flag', true);
try {
  await c.save(); // ✗ CLP blocks client writes to this class entirely
} catch (e) {
  console.log(e.code); // 119: operation forbidden by class-level permissions
}

// Flutter / Dart — Back4app Flutter SDK
// The class gate in action: reads allowed, client writes blocked by CLP
final config = ParseObject('Config')..set('flag', true);
final response = await config.save();
if (!response.success) {
  print(response.error?.code); // 119: forbidden by class-level permissions
}

// iOS / Swift — Back4app Swift SDK
// The class gate in action: reads allowed, client writes blocked by CLP
var config = Config()
config.flag = true
config.save { result in
  if case .failure(let error) = result {
    print(error) // operation forbidden by class-level permissions
  }
}

// Android / Kotlin — Back4app Android SDK
// The class gate in action: reads allowed, client writes blocked by CLP
val config = ParseObject("Config").apply { put("flag", true) }
config.saveInBackground { e ->
  if (e != null) {
    Log.d("CLP", "blocked: ${e.code}") // forbidden by class-level permissions
  }
}

Come i permessi di classe e le ACL lavorano insieme

La scala della granularità: CLP vs. ACL vs. pointer permissions vs. campi protetti

L’idioma di progettazione che ne deriva: le linee generali sullo schema, la grana fine sulle righe. Le classi la cui regola di accesso è uniforme (configurazioni, cataloghi, log) hanno bisogno solo della barriera della classe; le classi con dati per utente aggiungono ACL o pointer permissions al di sotto.

La stessa barriera in altri motori

-- PostgreSQL: i privilegi di tabella sono CLP con un altro nome
GRANT SELECT ON films TO PUBLIC;
GRANT INSERT, UPDATE ON films TO role_editor;
REVOKE ALL ON launch_codes FROM PUBLIC;

I database documentali lo riproducono con ruoli limitati ad azioni a livello di collezione – un ruolo con find e insert su una sola collezione. Il concetto è universale; ciò che cambia è l’ergonomia: i GRANT SQL e i documenti di ruolo si amministrano nel codice, mentre le piattaforme BaaS espongono la stessa matrice come interruttori nella dashboard.

Impostazioni consigliate per tipo di contenuto

Quella tabella è la checklist di cui ha davvero bisogno la maggior parte dei lanci – vale la pena notare la costante nell’ultima colonna e la sua regola sorella: creazione di classi dal client disattivata in produzione, così che lo schema cambi solo di proposito.

Casi d’uso tipici

• Congelare gli schemi di produzione. Add field disattivato dappertutto; le classi smettono di comparire e di mutare per effetto del traffico dei client.
• Dati di riferimento in sola lettura. Cataloghi e impostazioni leggibili pubblicamente, scrivibili solo dal codice server – lo schema Config qui sopra.
• Caselle in sola scrittura. Classi di feedback e telemetria in cui i client possono creare ma non leggere mai – la barriera inversa che il codice dello strato applicativo dimentica spesso.
• Superfici di amministrazione a livelli di ruolo. Update e delete riservati a un ruolo admin, mentre l’app legge liberamente.
• Difesa dal dump classico. La famigerata riga di comando – un curl con un app ID che interroga una classe User aperta – muore alla barriera find appena la classe richiede l’autenticazione.

Barriera della classe o codice server? Matrice decisionale

I due approcci si compongono: lo schema irrobustito per le classi davvero sensibili blocca interamente i CLP ed espone funzioni lato server come unica porta d’ingresso – la barriera della classe garantisce che nessuno aggiri il punto di passaggio.

Limiti e trade-off

• La granularità di classe è grossolana per definizione. Tutto ciò che è per riga appartiene alle ACL e alle pointer permissions; tutto ciò che è condizionale appartiene alla validazione lato server – i CLP presidiano, non ragionano.
• I valori predefiniti sono permissivi per lo sviluppo. Le classi nuove nascono aperte perché i prototipi corrano; la passata di prelancio che applica la tabella qui sopra è una disciplina, non un automatismo.
• La master key ignora tutto. Ogni barriera di questo articolo cade dove quella chiave circola – ed è per questo che vive solo lato server, usata operazione per operazione, mai distribuita.
• La superficie di applicazione deve essere completa. Le sottoscrizioni in tempo reale e gli endpoint speciali hanno avuto storicamente dei buchi di applicazione – conviene tenere la piattaforma aggiornata e provare le barriere da un client reale, non solo dalla dashboard.
• Anche gli interruttori vanno rivisti. La sicurezza dichiarativa è sicurezza verificabile solo se qualcuno la verifica – la matrice delle impostazioni appartiene alla checklist di lancio, non alla memoria collettiva.

I CLP su Back4app

Back4app è una piattaforma open-source di Backend as a Service (BaaS) che combina database gestito, API REST e GraphQL generate automaticamente, autenticazione, archiviazione di file e funzioni serverless con Cloud Code. I permessi di classe sono la sua superficie di sicurezza dello schema resa visiva: ogni classe nella dashboard porta la matrice delle operazioni come caselle da spuntare – pubblico, autenticazione richiesta, per ruolo – più le pointer permissions e i campi protetti, applicati lato server a ogni richiesta attraverso gli SDK, REST e GraphQL allo stesso modo. Al di sotto stanno le ACL per oggetto; al di sopra, i trigger di Cloud Code per le regole che hanno bisogno di logica. Le linee guida di sicurezza ripercorrono l’intera passata di prelancio – la matrice delle impostazioni di questo articolo, applicata clic per clic.