Sto lavorando alla conversione di un'applicazione che utilizza il pattern tradizionale Page Controller per iniziare a utilizzare il pattern Front Controller.
Uno dei potenziali problemi a cui sto pensando è che con un Front Controller potrebbe essere possibile per un utente malintenzionato chiamare direttamente funzioni arbitrarie.
Ad esempio, la richiesta di un URL come http://example.org/articles/read/123 chiamerebbe Articles::read( 123 ) , che è previsto, ma un utente malintenzionato potrebbe richiedere http://articles/some_random_helper_method/123 , che chiamerebbe Articles::some_random_helper_method( 123 ) . Questo metodo potrebbe influenzare lo stato del sistema, o informazioni sensibili sull'output, ecc.
Ovviamente cose come Articles::delete( 123 ) sarebbero dietro un meccanismo di autenticazione e nonces, ma potrebbero esserci delle funzioni di supporto che sono usate per costruire i risultati delle pagine pubbliche, ma non dovrebbe ancora essere chiamato arbitrariamente.
Questo sembra un problema comune, ma non sono stato in grado di trovare alcuna discussione su di esso.
Una soluzione sarebbe implementare una convenzione di denominazione (come _private_method() per distinguere tra metodi pubblici e privati, quindi impedire ai metodi che corrispondono a tale convenzione di essere richiamati. Questo è l'approccio che Code Ignitor usa.
Non funzionerà per me, perché sto convertendo un'applicazione esistente e rinominando tutti i metodi si romperebbe la compatibilità all'indietro. È anche soggetto a errori umani, perché si basa sullo sviluppatore che ricorda di anteporre il metodo se non è pubblico.
Un'altra soluzione sarebbe quella di fare affidamento sull'impostazione della visibilità dei metodi su pubblico o privato / protetto, ma che potrebbe anche rompere la compatibilità con le versioni precedenti nel mio contesto.
Un'altra soluzione potrebbe essere l'hardcodifica di una whitelist di metodi pubblici, ma ciò non sembra molto elegante.
Mi chiedo se esiste una soluzione canonica per questo problema?