Nella mia API di permessi, come gestisco oggetti che non esistono?

Sei sicuro che questo sia veramente un problema di permessi?

Esistono molti modelli di sicurezza a livello di oggetto esistenti, sia basati sui ruoli che basati su criteri, l'esempio più ovvio di ciò è l'ACL. Ogni oggetto può avere le proprie autorizzazioni, il che ha senso. Ma non c'è il permesso per "creare questo oggetto ", c'è solo un permesso per "creare un oggetto ". Potrebbero esserci delle restrizioni attorno al tipo di un oggetto che un utente può creare, ma di solito si tratta di ciò che accade.

Naturalmente, l'effettiva operazione di creazione di un oggetto potrebbe non riuscire per altri motivi. Ad esempio, l'oggetto potrebbe essere considerato un duplicato o potrebbe avere alcuni dati non validi o violare alcune regole importanti (un tweet troppo lungo, ad esempio). Non essere in grado, diciamo, di aggiungere una foto a un album fotografico che non possiedi, si tratta più di convalida della richiesta che di autorizzazioni sul (inesistente) oggetto.

Tra le opzioni che proponi, # 2 è probabilmente il più vicino alla modellazione delle autorizzazioni attuali senza fornire anche informazioni che non è possibile sapere per certo al momento (ovvero se la creazione di un oggetto o meno avrà successo). Lì non è un oggetto quando si effettua il controllo dei permessi, quindi se un utente può creare solo determinati tipi di oggetti, allora dovrebbe esserci un'autorizzazione diversa per ciascun tipo.

Potresti anche voler considerare che una funzione ultra-generica, taglia unica, sia spesso problematica proprio per questo motivo: ci sono sempre alcuni scenari che non si adattano e se cerchi di adattarli , si finisce con una specifica ambigua o difficile da usare. Ad esempio, un utente non dovrebbe essere in grado di porre la domanda, "Quali tipi di oggetti posso creare in questa posizione?" invece di doverlo calcolare uno per uno? Ovviamente non conosco tanto il dominio come te, ma consideri la possibilità che tu stia cercando di adattare 10 sterline in una busta da 5 libbre. Se l'API fosse più pulita avendo 2 o 3 o 10 funzioni invece di 1, l'espansione potrebbe essere la migliore risposta.

Usa lo schema del prototipo. In questo modello, crei un nuovo oggetto clonando un prototipo. Ovviamente ciò richiede che il prototipo esista. Solitamente non è una limitazione irragionevole, poiché nessun utente può creare oggetti casuali dal nulla. È improbabile che elgg_can("create BFG9000") funzioni per te: P

Poiché il prototipo deve esistere, può avere diritti di accesso.