Newsgroup: it.comp.java
Titolo: session tra due web application

Salve,
vi sembrerà banale la domanda ma non riusciamo a risolvere (ai noi).
Abbiamo due applicazioni web che risiedono sotto lo stesso tomcat.
webapps
     |_______app1
     |_______app2
La mia esigenza e che dopo un autenticazione da app1 si possa accedere
ad app2 e solo in questo caso.
Purtroppo non definendo una variabile di sessione su app1 con il
session.setAttribute
mi ritorovo in app2 un session id diverso e chiaramente la variabiel
concordata null.
Come posso fare?
Lo so è banale ma per noi è un problema.
Grazie infinite!!

 ad app2 e solo in questo caso.
Due webapp -> due ambienti disgiunti; quindi per comunicare ci vuole 
qualche altro sistema che non sia il passaggio in 'session' o 'application'.
Tempo fa ho fatto una cosa del genere:
- app1 autentica e mette nella session un oggetto con i dati dell'utente 
e un id univoco.
- app1 serializza l'oggetto e lo manda (openConnection e ObjectStream) 
ad un url di app2 dove una jsp deserializza e inserisce in una struttura 
hash dentro 'application'
- app1 fa il forward ad una seconda jsp di app2, fornendo l'id univoco 
di cui sopra
- a questo punto app2 ha l'id, guarda nella hash se trova i dati di 
utente inizializza una session e prosegue.
Probabilmente invece di serializzare la cosa si fa anche con un post fra 
le due jsp o con qualche altro sistema, ma non ho mai avuto tempo di far 
delle prove.
bye
DKano

DKano ha scritto:

Grazie era come immaginavo... infatti avevamo anche noi pensato alla
soluzione post (gia implementata) credevo che fosse una nostra mancaza
di conoscenze e.....sinceramente speravo che fosse più semplice
scambiarsi dati di sessione ma a quanto pare non è cosi.
Ciao e grazie ancora!

 scambiarsi dati di sessione ma a quanto pare non è cosi.
Può darsi che adesso ci sia qualcosa di già fatto, magari un 
jakarta-qualcosa... io la soluzione l'ho adottata molto tempo fa e 
allora non avevo trovato nulla; mi sono sempre detto che dovevo 
controllare se nel frattempo fosse venuto fuori un qualche sistema più o 
meno standard ma non ho mai avuto tempo (funziona-> non cambiarlo)
bye
DKano

Sto lavorando anche io su questa cosa:
siccome lavoro con WebSphere aggiungo che WebSphere mette a
disposizione la condivisione della sessione tra WAR contenuto nello
stesso EAR.
Al di là di ciò, stavo pensando anch'io ad una soluzione simile a
quella di Dkano ma meno elaborata.
Ossia:
EAR1: l'utente si autentica e gestisce l'autenticazione con la sessione
EAR1. Una servlet chiama un'altra servlet dell'EAR2 con il forward,
mettendo nella request con setAttribute un oggetto il cui stato
dipenderà dall'avvenuta autenticazione.
EAR2: la servlet ricevente cerca/legge tale oggetto e rigestisce
l'autenticazione (avvenuta).
Le mie domande sono:
1) perchè avete pensato ad un doppio passaggio di informazioni tra di
due mondi (considerato che il mittente è lo stesso)?
2) che intendevi con il fatto che hai messo in hash la prima variabile?
Aggiungo che, in teoria, penso si possano usare i meccaniscmi di Single
Sign On messi a disposizione dall'AS ma ancora non mi è chiaro come
funzionino (quindi se qualcuno lo sa...:-) ).
Ciao

pio...@inwind.it
 ha scritto:

Eheheh per rispondere alla domanda 1 dovrei dirti per chi sto
lavorando...ma sarei linceziato oggi pomeriggio.
Diciamo che nella app2 la profilatura costruita per l'accesso "deve"
essere "subalterna" alla profilatura di un portale che "deve" fungere
da "portale" per diverse application che ruotano intorno ad una unica
business logic.
Un saluto
AMC

 funzionino (quindi se qualcuno lo sa...:-) ).
Si, è vero... ma non ho idea di come funzionino :-) Ho fatto della roba 
sul SSO autogestita ma mi serviva fra due ambienti distinti (solo un 
canale https)
bye
DKano

 lavorando...ma sarei linceziato oggi pomeriggio.
Vuoi dire che hai dei boss che leggono it.comp.java? Wow!
:-)
bye
DKano

 In effetti così è più semplice. Dovrò trovare il tempo di far delle prove.
Ma funziona ? Non sono sicuro che il forward possa essere usato verso
risorse esterne al context della servlet....
Vorresti fare qualcosa del tipo :
request.getRequestDispatcher(servlet_app_2).forward(...) ?
Secondo me è in fondo ancora più semplice la proposta di usare una JSP
intermedia che "raccoglie" parametri ed attributi da app1 e li "spedisce" ad
app_2.
M'è venuta in mente anche un'altra possibilità:
1) app_1 traccia su supporto persistente gli oggetti in sessione usando l'ip
del client remoto come chiave;
2) redirect su app_2
3) app_2 carica sulla base dell'ip chiamante i dati dal supporto permanente.
Però potrebbero esserci problemi con proxy e firewall...
Scorpio.

Ne sono venuto a capo.
Ripeto che questo vale per WebSphere.
Sui web.xml dei due WAR contenuti ognuno in un EAR diverso si mette il
blocco di autenticazione solito così come segue (nella sua versione
più semplice):
	<security-constraint>
		<web-resource-collection>
			<web-resource-name>(Nuovo insieme di risorse
Web)</web-resource-name>
			<description></description>
			<url-pattern>*.do</url-pattern>
			<http-method>GET</http-method>
			<http-method>POST</http-method>
		</web-resource-collection>
		<auth-constraint>
			<description></description>
			<role-name>auth</role-name>
		</auth-constraint>
	</security-constraint>
	<login-config>
		<auth-method>BASIC</auth-method>
	</login-config>
	<security-role>
		<description></description>
		<role-name>auth</role-name>
	</security-role>
Se i due EAR sono deployati sullo stesso server, delegando la chiamata
del secondo  ad una servlet del primo, dopo aver eseguito
l'autenticazione richiesta, con qualcosa del tipo
		ServletContext context = getServletContext();
		context = context.getContext("/SecondWebSSO");
		context.getRequestDispatcher("/index.jsp").forward(req,resp);
e, avendo abilitato l'SSO nel menu LTPA di WebSPhere,
vedrete che il secondo EAR non richiederà l'autenticazione al primo
submit, così come farebbe/farà se chiamato direttamente