Newsgroup: it.comp.www.php
Titolo: e se uno avesse i cookies disabilitati?

Il visitatore del sito deve operare una scelta nella homepage (una sede
piuttosto che un'altra, e ad ogni sede corrisponde un Db differente),
questa scelta si propaga attraverso il sito tramite una sessione.
E' capitato che qualcuno abbia selezionato una sede e poi invece è stato
dirottato a quella principale di default, segno che la sessione non è
stata avviata.
Partendo dal fatto che il codice è corretto può essere che la causa sia
nel fatto che avesse i cookies disabilitati?
E se così fosse ci sono altri sistemi per evitare ciò?
Mi è venuto in mente l'url-rewriting, ma non so se esistano altri metodi
migliori, a parte avvisare il visitatore che deve avere i cookies
attivati.
Grazie
Max
-- 
http://www.maxori.it
L'Arte è la capacità di fare cose di nessun valore
e di riuscire a venderle
F. Zappa

 E se cosě fosse ci sono altri sistemi per evitare ciň?
Usi i parametri GET finché puoi.

 Usi i parametri GET finché puoi.
Era quello che temevo...


 Usi i parametri GET finché puoi.
Lo so che la mia e' paranoia, ma i parametri GET sono sull'URL e l'URL rimane
loggata nei proxy e assimilati. Io terrei presente anche questo nell'uso di GET
IMHO nulla vieta di dire "se vuoi continuare devi usare i cookies, se non usi i
cookies, non puoi continuare"
Ciao,
luigi
-- 
/
+--[Luigi Rosa]--
\
It's a poor workman who blames his tools.

 usi i cookies, non puoi continuare"
In effetti metterò un avviso nella splashpage e lascerò tutti i
meccanismi così come stanno.


 
Certo. Se non ti spiace perdere visitatori...

 attivati.
Usa il use_sessions_trans_sid (o simile, non ricordo il nome preciso) e 
poi evita la creazione delle sessioni per gli spider dei motori di 
ricerca (su internet trovi varie liste e basta cercare la stringa che 
identifica il motore nell'user agent).
Se la creazione di una sessione non è indispensabile usa sottodomini e 
rewriting. Cioè...
roma.miosito.it
 viene riscritto 
miosito.it?sede=roma
 
in tal modo l'utente senza cookie trova la sua sede, sui motori 
finiscono i sottodomini 
roma.miosito.it
, 
milano.miosito.it
 ecc...

 finiscono i sottodomini 
roma.miosito.it
, 
milano.miosito.it
 ecc...
Questa idea era venuta anche a me e avevo provato a buttare giù una
regexp, che però non funzionava..., ho anche provato a cercare in rete
ma non ho trovato molto, va bè che non ho avuto molto tempo per
lavorarci.
Hai un link per caso dove possa trovare un htaccess d'esempio?


 loggata nei proxy e assimilati.
Qualcosa invece impedisce ai proxy di registrare i parametri POST?
Poi non č che gli passa dei dati sensibili, parlavamo di un parametro 
per la sede o al limite un singolo id di sessione.

 attivati.
Se utilizzi la sessione esclusivamente per la scelta della sede, 
aggiungi la lingua direttamente nell'url (se hai l'accesso alla 
macchina, con un link simbolico risolvi tutti i problemi), della serie 
www.sito.it/sede1
 
www.sito.it/sede2
 etc... e da script facendo un 
parsing dell'url connetti il relativo db.
	Francesco

       Francesco
Purtroppo il sito è su Aruba e non posso modificare nulla sul server,
altrimenti avrei creato un sottodominio di 3° livello e con l' .htaccess
lo potevo tradurre da 
 
sede.dominio.com
in 
 
www.dominio.com/index.php?sede=$sede
ma non posso.
Il sito è già funzionante da tempo, a questo punto tanto vale rifare il
tutto ed usare l'url rewriting per propagare la variabile $sede e
renderlo un pò più indicizzabile.
www.dominio.com/sede/pagine/ecc/ecc
Detto ciò rimane da dire che alcune aree riservate devono per forza
avere le sessioni funzionanti, ma almeno dopo questo intervento il sito
diventerebbe usabile al 90%.


 Qualcosa invece impedisce ai proxy di registrare i parametri POST?
Non so gli altri software, ma in squid (
http://www.squid-cache.org/
) c'e'
un'opposita opzione per non loggare quel che c'e' dopo il '?' nell'URL. Pero' e'
sollo squid, non sul client.
Ciao,
luigi
-- 
/
+--[Luigi Rosa]--
\
The world potential market for copying machines is 5000 at most.
       --IBM, 1959

 nell'URL. Pero' e' sollo squid, non sul client.
La mia era una domanda retorica, ci si lamentava che i parametri GET 
restassero salvati sul proxy ma è chiaro che questo non fa alcuna 
differenza rispetto a quelli POST che possono essere salvati anche loro.
Questo se in discussione era l'aspetto "sicurezza".

 Questo se in discussione era l'aspetto "sicurezza".
Solitamente i proxy non loggano i contenuti dei POST.
Ciao,
luigi
-- 
/
+--[Luigi Rosa]--
\
Per aprire le finestre delle chiese russe bisogna
fare doppio click sulle icone.

 Solitamente i proxy non loggano i contenuti dei POST.
Il proxy puň loggare tutto o niente! Navigando tramite proxy bisogna 
accettare il rischio di essere loggati parzialmente o totalmente quindi 
o ti fidi del gestore del proxy o lo eviti!
	Francesco

 o ti fidi del gestore del proxy o lo eviti!
Vabbe', ma questo e' un discorso un po' generico che vale per ogni tipo di
trasmisisone in chiaro.
Ciao,
luigi
-- 
/
+--[Luigi Rosa]--
\
If God is perfect, why did He created discontinuous functions?

 
Sicuramente ma molte persone lo ignorano come credere più sicuro 
(utilizzando connessioni in chiaro) il post rispetto al get (security 
through obscurity).
	Francesco