cookies disabilitati & sessioni

[optime]

Originariamente inviato da Baol74
1.Una session che funziona SOLO nella stessa pagina non è una session.

non completamente vero.... immagina una pagina che richiama se' stessa...

[Baol74]

Se la pagina richiama sesetssa, il valore viene perso (ripeto, senza cookie la session è una semplica collection)

[optime]

ho fatto un paio di prove e pare di no...

[Gioba66]

Originariamente inviato da Baol74
1.Una session che funziona SOLO nella stessa pagina non è una session. Lo scopo ed il senso del concetto di sessione viene a cadere quindi è solo una variabile collection già creata dal sistema.
Dire che la session funziona ma solo all'interno della stessa pagina, ripeto a mio parere , è forviante, perchè il sistema delle sessioni non funziona!

affermazione di una superficialità notevole.
come detto, le session funzionano all'inetrno della stessa pagina.
fai questo semplice esempio, che ti confermano non solo nella correttezza della mia affermazione, ma ti fanno vedere anche un esempio pratico del perché può essere utile una session anche a cookies disabilitati....



pagina 1

<%

session("pippo") = "1"

response.write "pippo1 =" & session("pippo")

server.execute "pagina2.asp"

response.write "pippo3 =" & session("pippo")


response.end

%>

pagina 2

<%

response.write "pippo2 =" & session("pippo")

%>

[Baol74]

Forse si è perso il punto di partenza della discussione.

Le sessioni funzionano se i cookies sono disabilitati?
Risposta: No. Le sessioni non consentono di mantenere lo stato del client sul server se i cookies sono disabilitati.

Se poi si usano le sessioni per passare variabili da una pagina ad un'altra chiamata con server.execute mi sembra una questione che risponde ad un'altra domanda ed ad un caso particolare.

Dopodichè diciamolo:

Le sessioni non consentono di mantenere lo stato del client sul server se i cookies sono disabilitati.
Nonostante ciò c'è un caso in cui le sessioni non servono a mantenere lo stato ma vengono impiegate per un'altro scopo: Se le si usano per passare parametri da una pagina ad una sottopagina chiamata con server.execute. In questo caso, sappiate che funzionano.

Così va bene? E' un'uso proprio delle variabili di sessione secondo te? Matiene lo stato del client o serve a sopperire ad una mancaza di asp?

Infine esorto tutti ad utilizzare dei sistemi veri di inclusione dinamica e ads usare server.execute solo nei casi di inclusione di codice html o slegato dalla pagina chiamante

[Gioba66]

Originariamente inviato da Baol74

Infine esorto tutti ad utilizzare dei sistemi veri di inclusione dinamica e ads usare server.execute solo nei casi di inclusione di codice html o slegato dalla pagina chiamante

che discorsi sono questi?
come puoi paragonare un sistema di inclusione ad un server.execute?

lasciamo perdere, va...
ciao

[enricoska]

Originariamente inviato da Gioba66
con i cookies disabilitati le variabili di sessione funzionano ma SOLO nella stessa pagina dove sono state create;

Originariamente inviato da enricoska
stesso discorso coi cookies, nella stessa pagina funzionano anche se disabilitati.

Se non altro questo mi ha fatto capire che era inutile cercare di capire se l'utente avesse i cookies disabilitati provando a salvarne uno e a richiamarlo (nella stessa pagina) e controllandone il valore: il valore è sempre quello assegnato subito prima, anche se l'utente avesse i cookies disabilitati.

(p.s. a me interessava controllare la privacy "alta" che "danni" può fare un utente "non esperto" che smanetta sulla privacy...)

[Baol74]

che discorsi sono questi?
come puoi paragonare un sistema di inclusione ad un server.execute?

In che senso? La server.execute ha un limite enorme che conosciamo tutti e proprio per quello che si è costretti ad usere variabili di sessione in questo contesto ed a sproposito.

L'inclusione dinamica vera (http://www.aspxnet.it/public/files/download/include.zip) fornisce possibilità che la server.execute non è in grado di relizzare. Come la cattura del buffer (!!!!), l'esecuzione di codice javascript e vbscript nell'ordine corretto, lo sviluppo di nuove direttive (include url per esempio) ed altro ancora (ad esempio l'esecuzione di codice salvato in un database). Senza tralasciare naturalmente il fatto che tutto è eseguito all'interno dello stesso contesto di memoria (senza ricorrere a giochetti con le sessioni)

Il link sopra è una vecchia classe che ho sviluppato un paio d'anni fa, e già aveva molte potenzialità.

Il tempo di esecuzione è praticamente irrilevante. Tempo che diventa quasi nullo con l'aggiunta di tecniche di chacing.

La server.execute è una funzioncina in confronto a quello che si può fare con un buon sistema di inclusione dinamica!

Forse dovrei dirlo io a te. Come puoi paragonare la limitatezza della server.execute ad un vero sistema di inclusione dinamica?