Filter - form HTML in POST verso un filtro

[cagnaluia]

Originariamente inviato da andbin
Mi autoquoto (e mi infliggerò pesanti punizioni ) perché invece i cookie sono ok con il redirect. Ero convinto chissà perché che non venisserò inviati con il redirect.

Comunque, e questo è giusto, il fatto di usare encodeRedirectURL per sendRedirect è per lo stesso motivo per cui si dovrebbe usare encodeURL per generare i link. Se i cookie sono disabilitati, è l'unico modo di tenere "viva" la sessione.

infatti.. ero ben proccupato i giorni scorsi quando tentavo di fare il passaggio da una pagina all altratra tramite redirect, poi ho visto che invece funzionava.
Poi sbagliavo a fare il redirect alla pagina "buona" nel filtro... che invece non va fatto. piuttosto va fatto il contrario: tramite IF, controllo della sessione e redirect a qualcos altro se la variabile di sessione non soddisfa un requisito.



vaben: sistemo il "null".
segue: redirect diretto invece che refresh sull header.

[cagnaluia]

sto rivedendo il redirect e per quel caso, non importa, mi sta bene, visto che si tratta di login che si torni indietro o a registrarsi, anche perdendo la sessione.

(ok, dici tu, che potrei usare lo stesso filtro per tutte le altre servlet, hmm.. ok ci penserò.)

[andbin]

Originariamente inviato da cagnaluia
(ok, dici tu, che potrei usare lo stesso filtro per tutte le altre servlet, hmm.. ok ci penserò.)

Beh, sì, in generale per qualunque risorsa che vuoi "proteggere" (fintantoché mappi il filtro per quella/e risorsa/e ovviamente).
Perché la logica del filtro, come ho già detto, dovrebbe essere molto generica: utente loggato? Allora prosegui nel filter chain (alla risorsa finale o altro filtro in cascata ... ma quale/dove non dovrebbe interessare a questo filtro!). Utente non loggato? Allora vai ad una pagina di errore o quella di login o altro ... comunque non certo alla risorsa finale per gli utenti loggati!