Newsgroup: it.comp.java
Titolo: Giuro che impazzisco!!! Session!!

Salve, quello che mi succede mi sta facendo sentire male!
Ho delle pagine JSP che hanno funzionato perfettamente per mesi.
*ORA* quando prendo un oggetto con:
String codice=(String)session.getValue("codBand");
me lo prende in una pagina A e in un'altra B richiamata da A non lo prende 
più e mi dà null!!
Com'è possibile tutto ciò? scade la sessione in 10 secondi o cosa?! Io non 
invalido mai la sessione!
E la cosa ancora più strana che a qualcuno funziona mentre alla maggior 
parte no!
Aiutatemi please... 

 E la cosa ancora piů strana che a qualcuno funziona mentre alla maggior 
Cookies? La sessione puň salvare i suoi dati su cookies (il suoi id, 
almeno) Se non li hanno attivati possono capitare questi problemi. Se 
hanno aggiornato quel simpaticone di IE e lui si č attivato da solo 
tutte le opzioni di sicurezza (per il tuo bene, ovviamente :-) ) 
potrebbe esser questo il problema.
bye
DKano

Delio Nasso wrote:

Prima di impazzire fai qualche check preliminare, ok? ;)
Se prima funzionava e ora non piu', cosa e' cambiato
nel frattempo? Sei passato ad un altro servlet engine?
Hai modificato il tuo codice? Hai aggiornato delle librerie?
Sgombra la mente, conta fino a 10 e ricontrolla per bene: alle volte
non si vedono le cose piu' banali... ;)
Gia' che ci siamo, ti faccio anche notare che il metodo
getValue(java.lang.String) di javax.servlet.http.HttpSession
e' deprecato, perche' rimpiazzato da getAttribute(java.lang.String).
Ciao
Roberto

> Cookies? La sessione può salvare i suoi dati su cookies
Se così fosse non dovrebbe funzionare niente, ma come è possibile che per un 
po' mi muovo per le pagine prendendo i dati da là e poi in una data pagina 
cambia sessione?!?!
 

 e' deprecato, perche' rimpiazzato da getAttribute(java.lang.String).
Ok, grazie, provo a cambiare quello ma...

 
No sicuramente non e' quello il motivo: te lo dicevo
solo per completezza.

Delio Nasso ha scritto:

Completa l'anamnesi del problema. Prima di tutto verifica se, in questi
casi, hai due sessionid diversi. Visto che molto probabilmente è
così, il problema è quasi certamente dovuto alla sessione che viene
tracciata tramite cookie, l'ipotesi più probabile è che non funziona
con i cookie disabilitati.
Le soluzioni sono 2:
- Gestisci la sessione via URL
- Testi inizialmente l'abilitazione dei cookie e mandi in bianco
l'utente dicendo che il tuo sito funziona con i cookie abilitati.

 tag <meta> relativi alla cache. Io di solito uso questi:
Fatto, ma non va nemmeno così...
Non c'è un mdo esplicito per dirgli di non cambiare session? Se gli passo il 
session-id nell'url funziona? Non so proprio che fare... 

 - Gestisci la sessione via URL
Una volta passato l'id mi sai dire come recuperare l'oggetto session 
precedente?
Grazie 

Delio Nasso wrote:
 > Salve, quello che mi succede mi sta facendo sentire male!
 > Ho delle pagine JSP che hanno funzionato perfettamente per mesi.
 > *ORA* quando prendo un oggetto con:
 >
 > String codice=(String)session.getValue("codBand");
[CUT]
Sicuro che da entrambe le pagine A e B l'url del server sia lo stesso???
Mi spiego meglio: Se per caso da B accedi con l'indirizzo IP del server 
o magari semplicemente con un altro alias nel file hosts il cookie 
generato nella sessione di A non verrà visto.
Quindi se per caso accedi ad A con un indirizzo del tipo 
http://mioserver.it/A.jsp
e poi in b con 
http://mioserveralias.it/B.jsp
 benchè l'applicazione che 
risponde sia la stessa i cookie non verrebbero condivisi.
Comunque se ti fai scrivere l'id della sessione vedi subito se la 
sessione è cambiata oppure no...
Jack

 session-id nell'url funziona? Non so proprio che fare... 
Prima di trovare una soluzione e' meglio capire
la causa del problema: potrebbe ricapitarti e la
soluzione che adotti oggi domani potrebbe non funzionare.

 è cambiata oppure no...
è cambiata... 

Delio Nasso wrote:

Allora hai i cookie disabilitati, oppure l'host del
tuo server e' finito tra quelli per i quali non sono
accettati i cookie: prova a guardare nelle impostazioni
di sicurezza di IE.
Ciao
Roberto

 soluzione che adotti oggi domani potrebbe non funzionare.
Pure io vorrei capire ma non ne esco...
la sessione si mantiene per alcune pagine, poi quando vado a quella 
interessata cambia!
Non capisco proprio!!

 di sicurezza di IE.
Ma io prendo i dati dall'oggetto session per alcune pagine, poi in una 
pagina (senza apparente motivo, visto anche che ha sempre funzionato!)cambia 
sessione... 

Delio Nasso wrote:

A questo punto, senza sapere *esattamente* qual'e' la tua configurazione
ed il codice che viene eseguito, si puo' dire poco altro...
Ciao
Roberto

Salve,
ho trovato l'inghippo: se vado in opzioni internet->privacy e se abbasso il 
valore va! Mentre se lascio su medio non va!!
Ora tre domande:
1) perchč ha funzionato per mesi ed ora non piů?
2) perchč per la navigazione di altre pagine funziona e per quella no?
e sopratutto:
3) oltre a dire al navigatore di abbassare la protezione ci sono altre 
strade?
Grazie!! 

 strade?
L'unica cosa che puoi fare lato server è gestire la sessione via URL.


Una domanda al volo...ma hai provato con un altro browser per vedere se 
ti da gli stessi problemi??? Prova magari con Firefox...la questione che 
per alcune pagine la mantiene e SOLO per una non la mantiene mi sembra 
strana.

> L'unica cosa che puoi fare lato server è gestire la sessione via URL.
Se passo l'id della sessione via URL mi dici come fare a ricostruire 


 alcune pagine la mantiene e SOLO per una non la mantiene mi sembra strana.
Infatti con Mozilla č tutto ok... 

 l'oggetto session precedente?
Non occorre ricostruire nulla. E' il servlet engine che recupera la
sessione corretta tramite l'ID che gli passi.
Dai un'occhiata a encodeURL():
http://java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/servlet/http/HttpServletResponse.html#encodeURL(java.lang.String)

Ora funziona tutto!!!!!
Tutto è bene quel che finisce bene... :-)
Grazie mille!!!!!!!!!!!!!! 

 strade?
Probabilmente c'e' modo di dirgli che il tuo sito fa parte di quelli 
sicuri per cui la protezione deve esser ridotta.
Ci sarebbe anche l'alternativa di buttare Explorer, ma è solo un mio 
sogno :-)
bye
DKano

per le poche cose che ho fatto ho sempre gestito la sessione via URL. I
cookie dato che causano qs problemi li lascio perdere. A dire il vero
nn capisco il loro utilizzo in questo ambito se si sa che possono
essere disabilitati dagli utenti e che ciò puo causare problemi.
Perche si usano ugualmente?

 Perche si usano ugualmente?
Credo, perché se non metti in ogni url response.encodeURL il povero 
web-jsp-server non penso che da solo possa gestire la cosa modificando 
l'url autonomamente... allora prova a inserire l'id della sessione in un 
cookie.
bye
DKano

 Perche si usano ugualmente?
Aggiungo: Se vuoi memorizzare delle cose dell'utente che non scadano con 
la sessione come fai? O fai qualcosa lato server memorizzando in una 
qualche tabella l'utente e i suoi dati o usi dei cookies molto piů 
rapidamente.
bye
DKano

 
Perche' l'url rewriting e' una scocciatura: l'id della sessione
va inserito *esplicitamente* in ogni link ed in ogni form
e questo e' altrettanto foriero di problemi in fase di manutenzione
di applicazioni minimamente complesse.
Con i cookie ti dimentichi di dover gestire tu la sessione
e ti concentri sulle problematiche applicative.
Si puo' sempre controllare se il browser ha i cookie disabilitati,
nel qual caso si puo' visualizzare un messaggio all'utente chiedendogli
di riabilitarli per usufruire dei servizi applicativi: la maggior parte
delle applicazioni web si comporta proprio cosi'!
Ciao
Roberto

 delle applicazioni web si comporta proprio cosi'!
Infatti questo è il metodo migliore, secondo me. Non ti si incrociano 
gli occhi con tutti gli encodeURL e ti pari il... ehm ti cauteli contro 
errori incomprensibili e improvvisi avvisando prima l'utente.
bye
DKano

sickness ha scritto:

Perchè presuppone che *ogni* chiamata al server includa il sessionid
nell'url, altrimenti succede lo sgradevole inconveniente indicato in
questo thread ovvero perdi traccia della sessione.
Questo implica che qualsiasi link ad una tua pagina dinamica deve
essere generato a sua volta da una pagina dinamica e codificato con
encodeURL. Una scocciatura niente male.

io uso JSP da poco, ma almeno inserendo response.encodeURL() dove
serve, l'applicazione web che sto progettando funziona sia con i cookie
abilitati che disabilitati.
Quindi, sempre meglio scrivere una riga in più che fare una brutta
figura se il client ha disabilitato i cookie. Almeno io la penso così.
Sul manuale cè scritto:
Encodes the specified URL by including the session ID in it, or, if
encoding is not needed, returns the URL unchanged. The implementation
of this method includes the logic to determine whether the session ID
needs to be encoded in the URL. For example, if the browser supports
cookies, or session tracking is turned off, URL encoding is
unnecessary.
For robust session tracking, all URLs emitted by a servlet should be
run through this method

 Sul manuale cč scritto:
Quello che c'e' scritto sul manuale e' noto (almeno a me), ma forse e'
bene ricordare anche che quella frase sta li' scritta (esattamente nello
stesso modo!), sin dalla prima versione delle specifiche delle servlet API...
A quei tempi c'erano pochissime librerie di terze parti, non si parlava
di MVC (almeno in Java server-side), c'erano template engine embrionali,
ecc. ecc.
Da allora di strada ne e' stata fatta e le applicazioni sono diventate
piu' complesse e (normalmente) richiedono una separazione netta tra
business logic e livello di presentazione.
Tutto questo per dire che, nelle applicazioni minimamente complesse,
non e' (necessariamente) vero che "...URLs [are] emitted by a servlet...":
la costruzione delle URL e delle form puo' avvenire ad un livello nel
quale le API delle servlet non sono disponibili e, anzi, per motivi di design
potrebbe non essere conveniente esporre.
Ergo: puo' essere indispensabile basarsi sui coockie per mantenere traccia
delle sessioni.
In piu', gestire la manutenzione con l'URL rewriting puo' diventare un incubo!
Almeno io la penso cosi'. ;)
Ciao
Roberto

Mi puoi spiegare allora una curiosità che non trovo da nessuna parte?
non esitono file di sessione, come in PHP, dove vengono mantenute le
variabili o gli oggetti, dopo serializzazione, di cui si vuol mantenere
traccia. Quindi durante l'esecuzione di una applicazione web realizzata
in JSP in cui si utilizzano beans con  "scope=session", sono presenti
nella MEMORIA RAM del server  oggetti bean che mantengono le
informazioni di sessione associati ognuno ad un Client che sta
utilizzando l'applicazione web. Tali oggetti una volta che il Client se
ne è andato rimangono in memoria e poi tramite GARBAGE COLLECTION
vengono eliminati?
Vorrei sapere se ho capito il funzionamento o no.
Grazie
Ciao


Per quanto ne so io, questi sono dettagli implementativi che
dipendono dal servlet engine in uso.
In base alle specifiche (almeno per quello che mi ricordo...)
non interessa sapere *come* e *dove* vengono memorizzate le sessioni,
ma solo *cosa* il servlet engine deve *garantire* per quanto riguarda
il loro "ciclo di vita".
In particolare, il server non ha modo di sapere quando il client
"se ne va", ed e' per questo che vengono definiti timeout di sessione
(che poi fanno entrare in gioco il garbage collector).
Ciao!
Roberto

tutti_mi_chiamano_lupin ha scritto:

Si mi sa che è proprio cosi. I Bean possono inoltre essere
serializzati per poi essere riutilizzati ad es dopo un shutdown del
server. Almeno io ho capito cosi (v. implements Serializable). Grazie a
tutti per le risposte in merito ai cookie. Da oggi mi concentrerò sul
loro utilizzo. Magari qualcuno sa una procedura 'standard' per
l'intercettazione della disabilitazione dei cookie da parte del browser
utente? Sul mio libro ho trovato solo come settarli e riprenderli.
Ciao a tutti ;)