[PHP CMS] Comportamento CMS per richieste GET/POST non ammesse

[emanueledg]

Ciao,
nel mio CMS ho una feature che permette di verificare che le variabili inviate via GET o POST siano quelle abilitate.

Questo è derivato inizialmente da necessità SEO per evitare duplicazioni di URL derivanti dall'append di parametri a caso definiti dagli utenti nella query string, ma ne beneficia anche la sicurezza, ovvero lo script non sarà esposto ad altre variabili definite nella richiesta HTTP che non siano quelle stabilite dall'applicazione.
(Se pensate ci sia qualche falla in queste considerazioni dite pure).

Quello che su cui sto ragionando è quale sia il comportamento più corretto dell'applicazione in seguito all'inserimento di parametri non ammessi: al momento faccio un 404, ma mi chiedevo se non fosse una scelta troppo brutale.

Fare un 301 verso l'URL con i soli parametri ammessi è sensato nel caso di un GET, ma con POST si avrebbe un fastidioso alert da parte del browser che informa l'utente che i dati postati stanno in realtà per essere inviati ad una pagina slave diversa da quella inizialmente dichiarata come action del form, per cui minerei comunque la tranquillità e fiducia dell'utente nel servizio.

Avete suggerimenti per un comportamento dell'applicazione che non lasci l'utente eccessivamente contrariato? Oppure esperienze di comportamenti in situazioni simili da parte di altri CMS open source?

[maje]

Quello che su cui sto ragionando è quale sia il comportamento più corretto dell'applicazione in seguito all'inserimento di parametri non ammessi: al momento faccio un 404, ma mi chiedevo se non fosse una scelta troppo brutale.

se prendiamo i CMS più diffusi, Joomla!, Drupal, Wordpress, questo tipo di comportamento viene gestito esattamente come l'hai gestito tu, ovvero restituendo un errore 404 not Found, chiaramente su pagina personalizzata.

Quello è il codice HTTP pensato proprio per gestire situazioni di questo tipo, dunque non ci vedo nessuna "brutalità" anzi: comunichi nel modo corretto ciò che è avvenuto sul tuo sito (se ad esempio hai un sistema di logging, dovresti giustamente vedere un errore 404 di risorsa non trovata, e non un redirect no? )

[emanueledg]

Grazie mille per il tuo feedback.

Sulla semantica del codice di stato HTTP 404 sono d'accordo, non definisce esattamente quella casistica ma è abbastanza appropriato per l'occorrenza, per cui mi ponevo un problema di user-friendliness.

Se i CMS che hai citato gestiscono in questo modo quel tipo di richieste allora mi sento più sollevato nel conservare questa impostazione, solo che immagino si tratti di plugin aggiuntivi da installare, non caratteristiche dei CMS presenti di default... Da un controllo al volo, i fake URL seguenti mi risultano tutti dare un 200 a prima richiesta e cache vuota:

http://www.wordpress-it.it/tag/aggio...eter=idontknow
http://drupal.org/?errorParameterBlaBla=sometest
http://www.joomla.it/presentazione-j...si&fichetto=no

[maje]

non è un plugin, è il comportamento di default. Però occhio: i fake che hai postato potrebbero non rispettare il metodo corretto di passaggio di parametri per quei siti (che sono sottoposti a URL rewriting): in questo caso non vengono neanche presi in considerazione.

Mi spiego meglio: se le regole di riscrittura dell'url sono ad esempio

http://www.dominio.com/pagina/parame...rametro/valore (con parametro opzionale)

è chiaro che se gli passo un fake del tipo

www.dominio.com/pagina/?parametro=valore

restituisce la pagina corretta senza alcuna modifica => HTTP 202 come se il parametro non esistesse

Questo ad esempio segue il comportamento di cui abbiamo parlato poc'anzi:

http://www.wordpress-it.it/tag/aggio...eter=idontknow

[emanueledg]

Ho capito cosa intendi, ma io non parlavo dell'URL ricevuto dal controller (o dal router per smistarlo al controller stabilito), che è un identificatore della risorsa interno all'applicazione, ma parlavo dell'URL che l'utente invia all'host.

Posto che una modifica del REQUEST_URL (l'URI senza query string) di una risorsa deve causare un 404 se non individua alcuna risorsa, il quesito che mi ponevo era invece proprio sulla modifica alla query string o all'invio di parametri POST non abilitati dall'applicazione

Il fatto che in questo caso i CMS più diffusi restituiscano lo stesso codice di stato senza filtrare i parametri GET/POST ma accettando tutto, conferma il mio dubbio iniziale che il 404 sia un po' eccessivo...

Comunque leggendo la descrizione del codice di stato 202 di cui tu parlavi mi sembra che possa essere un valido responso per casi simili, ovvero: l'URL contiene parametri GET o POSTDATA non amessi -> l'applicazione accetta ugualmente la richiesta, riservandosi però il diritto di non completare la sua elaborazione.