Il mio team sta attualmente lavorando su un massiccio refactoring di un'applicazione di medie dimensioni in PHP. Stiamo facendo del nostro meglio per ridefinire il nostro codice su una base di moduli (ordini, utenti, prodotti). Il problema che mi sto attualmente ponendo riguarda la gestione di ciò che un utente è autorizzato a fare sul nostro sistema.
Attualmente, questo dipende principalmente dal Livello di accesso dell'utente al nostro sistema. A volte, potremmo dover fare riferimento al loro gruppo proprietario per vedere se il gruppo di livello superiore è autorizzato a fare qualcosa (effettuare un ordine) e passare tale autorizzazione in transito all'utente.
Quello che ho scoperto finora è una classe chiamata "Guardian". Guardian accetta un utente e quindi ha funzioni come "canPlaceOrder" o "canViewOrderReport". Un vantaggio di questo approccio è che siamo in grado di vedere tutte le azioni sul nostro sistema che richiedono autorizzazioni in un unico posto. Inoltre, ciò ci consentirà di separare la nostra logica di autorizzazione dai nostri modelli di front-end e di dominio.
Tuttavia, ho potuto vedere questa non essendo una soluzione completamente scalabile. Seguendo il principio OOP che una classe dovrebbe essere aperta per estensione, chiusa per la modifica, posso vedere che aggiungendo più autorizzazioni al nostro sistema, la nostra classe Guardian dovrà aggiungere anche altri metodi.
Mi piace il vantaggio di avere tutte le nostre autorizzazioni ben definite in un modo leggibile dall'uomo usando una classe, in modo che sappiamo sempre che stiamo controllando i criteri corretti. Tuttavia, sono preoccupato per la scalabilità. Ci sono altri approcci a questo problema?
La mia domanda è veramente: qual è un buon modo per gestirlo? La mia soluzione va bene?