Pro e contro della progettazione dell'applicazione PHP con un approccio di file pubblico?

Quando avvio PHP per la prima volta ho avuto la fortuna di avere accesso a un codice PHP di un gioco (che non è mai uscito tristemente).

Se inizi con tale progettazione senza framework dovrai gestire il routing in base ai parametri, non ci sono framework, routing centralizzato manuale.

Pro:

• Puoi centralizzare la gestione dei percorsi.
• È possibile aggiungere un controllo del livello principale dei diritti impedendo l'accesso ad alcune pagine con controlli di base (es .: isConnected, isAdmin, ovviamente è possibile fare cose più complicate a questo livello ma non lo consiglierò). Facendo questo puoi rimuoverlo che copia / incolla nella parte superiore di ogni file controllandolo e solo mantenendo un controllo specifico.

Contro:

• Codice aggiuntivo da sviluppare, che naturalmente potrebbe contenere difetti di sicurezza nel codice / design. Sì, se aggiungi un accesso di destra primario, rimuovi qualche codice di copia / incolla, invece devi sviluppare qualcosa di più elaborato.

• È necessario centralizzare tutte le dichiarazioni di navigazione nel file di routing o nel database. Se si sceglie la modalità del database, consiglio vivamente di rimuovere il privilegio di scrittura sul tavolo all'utente dell'applicazione e di modificarlo da sé con un altro account privilegiato che l'applicazione php non usa mai. Almeno se c'è qualche iniezione SQL, l'iniezione non sarà in grado di modificare quel livello di accesso corretto.

Se usi un framework, Pro e Coins sono ancora validi, ma non sono più le tue preoccupazioni dal momento che hanno fatto il lavoro per te. L'unica cosa è ottenere come aggiungere la tua nuova pagina e gestirne l'accesso.

Nella tua implementazione, index.php servirà come Front Controller . Questo approccio è utilizzato nella maggior parte, se non in tutti, i principali framework web PHP:

• Symfony
• Laravel
• Slim

Vedi anche questa discussione correlata su SO

Il pro principale è una maggiore sicurezza, beh, questo è possibile se configuri correttamente .htaccess .

Reindirizzando tutto al file di indice pubblico e negando l'accesso ai file delle fonti delle applicazioni, estrai i diritti di accesso di file e directory ad apache, il che fa un buon lavoro.

Ora quei file dell'applicazione non solo contengono la tua logica aziendale ma possono anche contenere informazioni sensibili, come credenziali del database, chiavi API del server, .. Informazioni che non vuoi che nessuno veda.

Quando apache si occupa di negare l'accesso a tali directory / file e di riscrivere l'URI, tu stesso puoi descrivere elegantemente cosa e come si accede.

Un approccio manuale risulta molto complicato e potresti facilmente commettere un errore e avere un file, che volevi essere inaccessibile, accessibile.

Il problema è che ogni richiesta che colpisce il server ora deve passare attraverso questo file di indice pubblico. E quando crei una directory come scripts in cui vuoi posizionare il codice da eseguire passando a un URI nel tuo browser, di solito non funziona, perché il framework non si rende conto che vuoi effettivamente accedere a un file .php (sarà nemmeno ti lascia) e pensa che stai provando ad accedere a un controller.

Ovviamente, questo viene aggirato eseguendo lo script direttamente da diciamo SSH, quindi non passa attraverso Apache. Ma anche in questo caso è necessario pensare al progetto e probabilmente non inserire la logica di bootstrap (inizializzazione dell'ambiente, ...) nel file di indice pubblico - questo è ciò che per fortuna fanno molti framework.

Alla fine, se non stai codificando per scopi educativi, non ti consiglio di tirar fuori la tua soluzione. Esistono molti framework che utilizzano la methology del file di indice pubblico singolo e sono piuttosto maturi e si sono dimostrati efficaci.

Lungo i framework che FMJaguar ha già menzionato, ti consiglio vivamente il PhalconPHP framework.