[Java] J2ee: Processare la richiesta originaria dopo il forward alla pagina di login

[anx721]

Lo scenario è questo:

l'utente clicca su un link ad una pagina che per essere visualizzata necessita di aver fatto il login (ad esempio un utente non loggato in questo forum che clicca sul pulsante per rispondere ad una discussione.) Tramite un filtro riesco ad intercettare tutte le richieste a tali pagine e se l'utente non è loggato le ridirigo (conun forward) alla pagina di login; quando l'utente immette i dati di login, se sono corretti, voglio che ci sia il forward alla pagina originale che l'utente aveva richiesto. Ora se la richiesta originaria non conteneva parametri non ci sono problemi: quando il filtro ha processato la richiesta originale ha potuto salvare l'url richiesta che puo essere utilizzata dopo il login; se la richiesta conteneva parametri è pero un problema. Se utilizzassi solo servlet e jsp potrei salvare tutti i parametri e poi utilizzarli dopo il login. Il fatto è che sto usando Struts, chi lo conosce sa che Struts ha un flusso di richiesta/validazione dei parametri/forwording abbastanza rigido. In particolare dopo il login non possono semplicemnte fare il forward alla url originaria, perche tale url corrisponde ad un'azione che riceve un ActionForm che viene popolato automaticamente con i parametri della richiesta, ma questi parametri ora sono i prarmetri del form di login, non i parametri della richiesta originaria.

L'unca soluzione che mi viene in mente è questa:

1 - qando arriva la richiesta originaria il filtro esegue il forward alla pagina di login; questa ha un form con i campi username e password, in questo caso io dovrei inserire in tale form tanti campi hidden quanti sono i parametri inviati con la richiesta originaria in modo che vengano rispediti assieme al login;

2 - quando avviene il login l'ActionForm associato contiene i dati del login ma anche tutti i dati della richiesta originaria, per cui le richiesta può essere forwardata all'azione originaria che si ritroverà nel form i dati di cui ha bisogno.


Questa soluzione pero non funziona in generale: se ho due o più url che richiedono il login prima di essere visualizzate e che ricevono ActionForm di tipo diverso non posso stabilire a priori il tipo del form associato all'azione di login, perchè in un caso tale form contiene certi campi, in altri casi ne conteine altri; dovrei quindi usare un tipo di form dinamico, mi pare ci siano i mapped back form che consentono di racchiudere i valori dei parametri in una mappa, per cui i parametri nel form possono essere in numero arbitrario.

Vorrei sapere se cisono oluzione standard visto che mi pare uno scenario frequente, grazie e ciao.

[pinok]

Se non ho capito male, il tuo problema è che non sai a priori come mappare i campi nascosti della form, perché in un caso potrebbero essere A, B, C e in un altro pippo, pluto e paperino.

Se è così, non puoi creare dinamicamente la form in base ai campi della request, che possono essere recuperati con request.getParameterNames()
Questo metodo della request ti dà una Enumeration, per cui ti potresti creare un loop che scandisce tutti gli elementi della enumeration, crea gli input nascosti con il nome recuperato dalla enumeration stessa e un valore pari a un getParameter eseguito di volta in volta con il nome appena estratto.

Spero di non essermi attorcigliato troppo la lingua nella spiegazione

[DvL^Nemo]

Originariamente inviato da anx721

Lo scenario è questo:

Vorrei sapere se cisono oluzione standard visto che mi pare uno scenario frequente, grazie e ciao.

Di standard c'e' questo

http://infinity.crosslogic.com/clinf...entication.pdf

Non so se si lega bene con struts.. Io l'ho utilizzato in abbinamento a serlvt+jsp e funziona benissimo..
Ciao !

[pinok]

Originariamente inviato da DvL^Nemo

Di standard c'e' questo

http://infinity.crosslogic.com/clinf...entication.pdf

Non so se si lega bene con struts.. Io l'ho utilizzato in abbinamento a serlvt+jsp e funziona benissimo..
Ciao !

Niente di nuovo, è la classica autenticazione prevista da Tomcat.
Personalmente non mi piace per due motivi.
L'autenticazione BASIC non ti permette di personalizzare i parametri da inviare, fa proprio e solo il controllo di accesso.
Quella mediante FORM, per quello che avevo visto, ha un difetto: mantiene si la conoscenza della pagina a cui accedere dopo l'autentica (presumo anche i dati della relativa query), ma se qualcuno mette nel bookmark la pagina con la form di autentica e cerca di partire da lì, Tomcat poi non sa più dove andare. Bisogna lavorare su quella pagina in modo che identifichi eventualmente l'esistenza o meno di un utente autenticato e lo reindirizzi ad una home page successiva. Inoltre, se l'obiettivo è proprio quella della home page successiva all'autentica, bisogna modificare tutte le pagine del sito affinché l'utente che cerchi di "piombare" nel centro dell'applicazione, venga rimandato all'inizio (ad es., quando per accedere ad una pagina si vuole che abbia letto una premessa, ecc.)

IMHO