Newsgroup: it.comp.www.php
Titolo: Mantenimento di una sessione

Salve a tutti.
Vado diretto al nocciolo della questione: per mantenere i dati di un 
utente loggato da una pagina all'altra attualmente uso $_SESSION.
Con mio profondo rammarico ho però constatato che, qualora uno abbia 
disabilitato i cookies, la session_start() fornisce un diverso id ogni 
volta che si cambia pagina e quindi mi perdo i settaggi dell'utente loggato.
Dal momento che personalmente ritengo semplicemente OSCENO propagare 
l'id di sezione tramite il link, in quale altro modo posso mantenere i 
dati di un utente loggato tra pagina e pagina?
Da tenere presente che non ho modo di modificare il file php.ini ne 
installare add-on ad hoc, in quanto il concessionario dello spazio web 
non me lo permette (e' un servizio gratuito e quelle sono le condizioni).
Una prima soluzione che avevo considerato era quella di archiviare 
l'accesso memorizzando su un database l'indirizzo IP, anzichè l'id di 
sessione, ma ho dovuto scartarla in quanto, se due persone accedono da 
una sottorete gestita da un router l'IP che risulta al server e' lo 
stesso (quello del router) e quindi la chiave non sarebbe univoca.
Ciò rende inutilizzabile questa soluzione per i miei fini, visto che la 
maggior parte degli utilizzatori del sito sono colleghi della mia stessa 
azienda e accedono ad internet dalla medesima sottorete gestita dal 
medesimo router (e, per scelta aziendale, hanno i cookies disabilitati).
Qualche dritta?
Lucignolo
-- 
Sign in progress

 mantenere i dati di un utente loggato tra pagina e pagina? Da tenere
Non puoi, come hai giustamente notato anche tu.
HTTP e` stateless, quindi o lo passi nell'URL (in GET) o lo passi negli 
header (con i cookies). Non hai scampo.
Aggiungo che, ad oggi, secondo me e` semplicemente stupido disabilitare i 
cookies.
Bye.

 pagina e pagina?
Nessuno.
Se il client non gestisce i cookie di sessione, l'utente avra'
difficolta' a navigare moltissimi siti.
P.S.
Anche trovandolo osceno, l'unica alternatica che assicura la
propagazione della sessione e' passare il SID tramite GET/POST.
-- 
Vuoi distribuire il tuo sito web su CD/DVD?
Prova 
http://www.dwebpro.com/
Vuoi diventare un esperto analista PHP/MySQL?
Vieni a fare uno stage con noi: 
http://www.creativepark.it/stage/

 cookies.
Purtroppo non posso interferire con le scelte aziendali quindi, stupido 
o no, devo mettere in conto che la situazione e': cookies disabilitati.
La parte che riguarda gli utenti loggati è talmente limitata che il 
dover propagare l'id di sessione in TUTTE le pagine del sito lo trovo 
davvero rivoltante e sono certissimo che non lo attuerò.
Quella però di non avere nemmeno un'area su cui memorizzare delle 
variabili valide per tutte le pagine la trovo una gravissima mancanza 
del PHP. Persino il tanto deprecato ASP ce l'ha!
Grazie comunque per l'aiuto.


 tanto deprecato ASP ce l'ha! Grazie comunque per l'aiuto.
No.
ASP ha un'area di "memoria" condivisa tra tutte le applicazioni 
sull'application server. O variabili condivise nella stessa applicazione.
Puoi fare la stessa cosa anche in PHP, anche se "manualmente" (basta 
creare una piccola classe che richiami da ovunque tu voglia e salvi roba 
in /tmp, per esempio).
Ma senza cookie e senza passare roba in GET, nemmeno scrivendo in 
sanscrito antico riuscirai a mantenere dati di sessione propriamente detti.
A meno di applicazioni che sostituiscono tutti i link <a> con dei <form 
method="post"> e che embeddano le variabili li` dentro, ma questo e` 
quello che IO chiamo rivoltante.
Bye.

 Persino il tanto deprecato ASP ce l'ha!
Allora fallo in ASP. Poi spiegami come ci sei riuscito. Ma non ci sarai
affatto riuscito.
ciao, f.

,
 
f...@despammed.com
 (Cujo) wrote:
[CUT]
e ora devo leggere il thread per curiosità...

 del PHP. Persino il tanto deprecato ASP ce l'ha!
Come fai a mantenere le sessioni in ASP senza cookie ne passando il SID
tramite GET/POST?
L'oggetto Application di ASP puo' essere tranquillamente sostituito da
un qualsiasi archivio di dati centralizzato (es. file/database).


POST e un cookie.
Cinque. Puoi pensare ad una autenticazione lato utente.
Poi puoi simulare un handler di sessione che utilizza... il nome utente
come session ID. Ovviamente devi validare la password.
(Il quinto metodo e' lo stesso ma credo non funzioni piu', e utilizza a
mo' di SESSID il nonce di un Auth-Digest. Bad juju there).
Leonardo
--
The stars have not dealt me the worst they could do:
My pleasures are plenty - my troubles are two.
But oh!, my two troubles, they reave me of rest:

Qualche dritta?
Come si dice: puoi fare le nozze con i fichi secchi, ma perdiana, almeno
i fichi secchi comprateli! :-D
Comunque, oggi anno del Signore 2008, navigare a cookie spenti vuol dire
che meta' siti non ti funzionano bene. E in cambio ottieni cosa? Niente!
Almeno tu mi dicessi: hanno disattivato Javascript; ecco anche li' meta'
siti non ti funzionano, MA ALMENO hai piu' sicurezza [flamers take note,
ho detto "piu'" sicurezza, non "sicurezza totale"...].
Ma levare i cookie... mah!


 Cinque. Puoi pensare ad una autenticazione lato utente.
'azz. Hai ragione ;), 
però ho il sospetto che php debba girare come modulo del webserver
perchè abbia accesso alle informazioni di autenticazione passate dal
browser al webserver. Se php gira come CGI non credo sia possibile.
ciao, f.

browser al webserver. Se php gira come CGI non credo sia possibile.
Credo si possa sempre, non so in quale variabile di _SERVER va a metterlo,
e potrebbe servire - forse - .htaccess invece che fare "in proprio"; pero'
fare si dovrebbe poter fare: che i CGI non possano sapere l'utente con cui
stanno parlando e' fantahorror :-D


 stanno parlando e' fantahorror :-D
MMMM. Not quite.
Almeno nella mia esperienza, ma accetto smentite (documentate) ;)
"come cgi" io intendo (supponendo apache come webserver) che php č
configurato (in httpd.conf) piů o meno cosě:
AddType application/x-httpd-php php
Action application/x-httpd-php /cgi-bin/php 
In questo caso non vedo proprio come php - che viene istanziato volta
per volta come process A SE STANTE - possa apprendere tali informazioni
senza che apache glie li passi. Con questa configurazione, fatta cosě,
ti garantisco che php non viene a sapere nulla e gli elementi opportuni
di $_SERVER restano "blank". Non dico che sia IMPOSSIBILE farlo. Ma php
dovrebbe ricevere tali informazioni da apache all'atto della chiamata.
Viceversa, come modulo del webserver (ie: LoadModule) ovviamente
funziona, ma la cosa non mi sorprende perchč il processo č lo stesso.
Settato cosě č come sa apache stesso fosse in grado di "parsarsi" i file
.php da solo.
ciao, f.

 nulla e gli elementi opportuni di $_SERVER restano "blank".
Sotto IIS, con PHP come CGI ed autenticazione HTTP puoi ottenere i dati
di autenticazione inseriti dall'utente tramite:
$_SERVER['AUTH_USER']
$_SERVER['AUTH_PASSWORD'] 
Sotto Apache 2.0.52 con PHP installato come CGI puoi ottenere il nome
dell'utente tramite $_SERVER['REMOTE_USER'].
IIS ed Apache forniscono al PHP i dati secondo le specifiche CGI/1.1
(vedi 
http://hoohoo.ncsa.uiuc.edu/cgi/env.html
).


 (vedi 
http://hoohoo.ncsa.uiuc.edu/cgi/env.html
).
Ti ringrazio per la precisazione.
Quando usavo php cme CGI non andava, ma da qualche anno ho "droppato"
tutta la "storia" CGI + SUEXEC perchč alla fine della fiera non mi
serviva e le prestazioni ne soffrivano un bel po'.
Al momento non ho modo di riprovare quindi, ma prendo atto di ciň. ;)
ciao, f.

Vi spiego tutta la faccenda: io e altri miei colleghi stiamo lavorando
all'interno di una ditta (chiamiamola A) come consulenti esterni mandati
da un'altra ditta (chiamiamola B).
Ogni fine mese tutto il mio gruppo deve compilare quello che in gergo si
chiama "rapportino" e, secondo le specifiche della ditta B, dovrebbero
scrivere tutto su dei fogli excel (o su un file di testo) che poi
invierebbero a me: con quei dati io compilo un foglio Excel contenete le
presenze di tutti, il totale ore di ogni singolo e il totale di tutto il
gruppo e poi lo spedisco alla ditta B.
Sono il responsabile del gruppo, quindi dovrei anche sapere sempre chi
c'è, chi non c'è, ecc., pur essendo spalmati su tre piani diversi.
Se dovessi mettermi li a chiedere chi c'è e chi non c'è, a salvarmi le
ore di tutti giorno per giorno e altre cose del genere perderei un sacco
di tempo (oltre a rompermi oltremodamente i maroni) e allora cosa mi 
sono inventato: siccome avevo già creato un sito di cazzeggio dove si
pubblicavano barzellette, dritte e una sorta di diario interno, ho
aggiunto una sezione che che permette ai miei colleghi di compilare
anche il rapportino direttamente da li.
In questo modo io ho sempre in tempo reale la situazione 
presenze/rapportini, sia dalla ditta A che da casa.
La versione ALFA (quello che gira adesso) funziona così: sulle pagine 
(due, per ora: rapportini e cazzeggio) che prevedono un inserimento sul 
database come campi compaiono anche userid e password. Chi ci scrive 
deve mettere i suoi dati e, al momento del submit, il modulo che 
provvede all'inserimento vero e proprio li verifica: se è tutto ok, i 
dati vengono registrati a nome di quell'utente altrimenti no.
Spartano, grezzo e bruttino, lo so, ma tenete conto che tutto questo
servizio è stata una MIA iniziativa, di cui nessuno mi riconosce un euro
ne per la realizzazione ne per il mantenimento: per questo mi
sono appoggiato ad un fornitore-servizi gratuito.
Ci lavoro, quando ne ho voglia, nei miei momenti liberi.
La ditta B ne è al corrente, ma tanto a loro basta che gli mandi il
foglio excel con i dati compessivi: come gestisco internamente i
rapportini e le presenze sono affari miei.
Quanto alla ditta A, a sentir loro è già tanto che ci concedono
l'accesso a internet, figuriamoci avanzare anche delle pretese.
Ecco che arriviamo alla mia domanda di poter mantenere la sezione senza
propagare il session-id: avevo già messo a punto in locale una versione 
BETA con qualche altro servizio personalizzato e la sua bella
paginetta login/logout, quando mi sono accorto che con i 
coockies-disabilitati la sessione va a donnine.
Se era fattibile aggirare questa penisola ('questo scoglio' sarebbe 
stato troppo riduttivo) l'avrei messa on-line ma se il prezzo da pagare 
per vederla girare e' dover propagare il session-id in tutte le pagine 
allora non ci siamo neanche un po: assolutamente non ne vale la pena!
Se e quando mi inventerò qualcosa di meglio, bene; se no continueranno
come hanno fatto finora.
Grazie comunque a tutti per l'aiuto e per il tempo che mi avete dedicato.


 Ma levare i cookie... mah!
Il fatto č che č una scelta sulla quale non posso fare nulla.


 che un utente si logghi due volte, quindi sarebbe stato perfetto.
Come viene eseguito PHP da Apache?
Hai creato un'area protetta (directory) tramite autenticazione HTTP?
Hai provato ad insere uno script PHP in quella directory con questo
codice?
<pre><?php print_r($_SERVER); ?></pre>


 
wrote:
[CUT]
Mah.
Vuoi uno strumento che ti semplifichi il lavoro ma non vuoi affinarlo 
troppo perché nessuno ti riconosce un euro ma il tuo tempo e la fatiche 
risparmiati non valgono forse?
Inoltre non vuoi usare gli id sessione in GET anche se avresti già 
risolto? Mi sembra una maniera oltremodo strana di procedere, è uno dei 
pochi casi in cui i computer servono a qualcosa (il resto del tempo che 
spendiamo è cazzeggio) e io non ci avrei certo pensato due volte se mi 
fosse tornato comodo.

Niente: non mi ritorna nessun valore.
L'area e' autenticata con .htaccess? Perche' se no e' normale che non ti
ritorni nessun valore.
Userid e password, invece di metterli via PHP, li metti via .htaccess (e
.htpasswd). Se $_SERVER[REMOTE_USER] e' settato, sai che la pass e' OK -
anche se non sai quale fosse - e puoi leggerti i dati dell'utente. Tutte
le pagine nella directory contenente il .htaccess avranno REMOTE_USER, e
il tuo problema e' risolto.
...se no invoca Geronimo, come nella barzelletta :-)


 Grazie comunque a tutti per l'aiuto e per il tempo che mi avete dedicato.
... l'ho letta tutta e non mi immaginavo certo una situazione del genere !
Io non avrei dubbi, passerei l'id di sessione in GET perchè risolverebbe 
il problema ed in quel contesto la pulizia "architetturale" è abbastanza 
  irrilevante (mi sembra).
Perchè ti ostini a non volerlo usare ?
ciao, f.

 <pre><?php print_r($_SERVER); ?></pre>
Si, ecco il risultato:
     [SCRIPT_URL] => /Beta/phpinfo.php
     [SCRIPT_URI] => 
http://pippo.altervista.org/Beta/phpinfo.php
     [HTTP_HOST] => 
pippo.altervista.org
     [HTTP_USER_AGENT] => Mozilla/5.0 (Windows; U; Windows NT 5.1; it; 
rv:1.8.1.12) Gecko/20080201 Firefox/
2.0.0.12
     [HTTP_ACCEPT] => 
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
     [HTTP_ACCEPT_LANGUAGE] => it-it,it;q=0.8,en-us;q=0.5,en;q=0.3
     [HTTP_ACCEPT_ENCODING] => gzip,deflate
     [HTTP_ACCEPT_CHARSET] => ISO-8859-1,utf-8;q=0.7,*;q=0.7
     [HTTP_KEEP_ALIVE] => 300
     [HTTP_CONNECTION] => keep-alive
     [PATH] => /sbin:/bin:/usr/sbin:/usr/bin
     [SERVER_SIGNATURE] =>
     [SERVER_SOFTWARE] => Apache
     [SERVER_NAME] => 
pippo.altervista.org
     [SERVER_ADDR] => 75.126.23.99
     [SERVER_PORT] => 80
     [REMOTE_ADDR] => 151.xx.xx.xx
     [DOCUMENT_ROOT] => /var/www/html
     [SERVER_ADMIN] => 
in...@altervista.org
     [SCRIPT_FILENAME] => /membri/pippo/Beta/phpinfo.php
     [REMOTE_PORT] => 1112
     [GATEWAY_INTERFACE] => CGI/1.1
     [SERVER_PROTOCOL] => HTTP/1.1
     [REQUEST_METHOD] => GET
     [QUERY_STRING] =>
     [REQUEST_URI] => /Beta/phpinfo.php
     [SCRIPT_NAME] => /Beta/phpinfo.php
     [PHP_SELF] => /Beta/phpinfo.php
     [PATH_TRANSLATED] => /membri/pippo/Beta/phpinfo.php


 ritorni nessun valore.
No. Mi sono espresso male: non ho un area riservata nel senso che c'è 
una directory per pochi eletti. Quello che intendevo è che in alcune 
pagine, se sei registrato, ti compaiono più voci di menù (quelle che 
permetterebbero di inserire i dati e/o di modificarli)
Il sito è tutto sulla stessa directory e non è autenticata. I dati vanno 
sempre e solo sul DB, non sul sito.


 Perchč ti ostini a non volerlo usare ?
L'idea di ritoccare tutte le pagine per portarmi dietro un dato che 
serve veramente solo in due proprio non mi va giů!
Per me non migliora ne peggiora nulla se rimane come č adesso.
Se si poteva fare in modo indolore, bene.
Non si puň? Pazienza: č da 1 anno circa che č cosě e ha sempre fatto 
egregiamente il suo lavoro.
Io sono dell'idea che i cambiamenti strutturali hanno senso solo quando 
il beneficio che portano supera lo sbattimento per attuarli.
Questo caso, per me, non ci rientra.


 fosse tornato comodo.
Ma infatti PER ME non sarebbe stato più comodo di come è adesso. Sarebbe 
stato solo un po' più bello, se si poteva fare.
Non si può? Pazienza: resta come è adesso!


 inserisce cazzoculocazzoculo nel db.
DEVI proteggere la cartella tramite autenticazione HTTP per poter
ottenere la valorizzazione di $_SERVER['REMOTE_USER'].


 che modo lo propago?
Se la direttiva session.use_trans_sid e' abilitata, ci pensera' il PHP
a propagare il SID tramite i tag definiti da url_rewriter.tags.


 serve veramente solo in due proprio non mi va giů!
[..]
MA ...
Non devi mica farlo tu ! ;)
Leggi qua:
http://it.php.net/manual/en/ref.session.php#ini.session.auto-start
In particolare la parte "Passing the Session ID".
(Hint: --enable-trans-sid)
ciao, f.

 Infatti. Ma il sito già adesso funziona e lo scopo prefissato lo raggiunge.
Ah avevo capito il contrario, perfetto allora.

 ottenere la valorizzazione di $_SERVER['REMOTE_USER'].
Forse mi sono spiegato male: non è che c'è un'area riservata nel senso 
che c'è una directory solo per pochi eletti: il sito è tutto sulla 
stessa directory ed e' fruibile da chiunque.
Semplicemente, nei menù comparirebbe qualche opzione in più a chi è 
iscritto.
Non è che ci sia chissà quale segreto da difendere con la vita.
Sei un normale utente? Vedi "Leggi le barzellette";
Sei un iscritto? Vedi "Leggi le barzellette - Inserisci nuova barzelletta".
Una cosa così, capisci?
Ora chiunque vede anche "inserisci", solo che nella pagina 
dell'inserimento, tra i campi da riempire, compaiono anche user e 
password. Se non li compili o se non risulti iscritto, al momento del 
salvataggio ti dice che non ha salvato niente.


 salvataggio ti dice che non ha salvato niente.
Inserisci gli script di inserimento all'interno di un'area protetta
tramite autenticazione HTTP ed il problema e' risolto (autenticazione,
mantenimento della "sessione" senza cookie/SID etc).


 a propagare il SID tramite i tag definiti da url_rewriter.tags.
A quanto ne so č abilitata, ma forse non ho capito come estrarlo.Io ho 
fatto cosi':
sul server dove ho il sito ho inserito due pagine:
prova.php
<?
session_start();
echo "- " . SID;
echo '<br /><a href="provadue.php">vai</a>';
?>
provadue.php
<?
echo "PHPSESSID=" . $_GET['PHPSESSID'];
echo "<br>SID=" . SID;
echo '<br /><a href="prova.php">inizio</a>';
?>
Quando faccio partire il browser con prova.php, la prima volta vedo:
- PHPSESSID=7ed1d0b6f26305f98703363d450be9d8
_vai_
se clicco su vai vedo solo
PHPSESSID=
SID=SID
_inizio_
(ovvero il valore che sembrava dovesse trovarsi in PHPSESSID č vuoto e 
pure SID arriva vuoto)
se clicco su inizio torno su prova.php, ma addirittura mi ritorna
-
_vai_
(ovvero il SID, che al lancio era valorizzato, ora mi ritorna bianco)
Quindi la domanda č: cosa sto sbagliando?


 ?>
Non usare l'open short tag. Utilizza il tag di apertura completo.
SID e' una costante che viene valorizzata SOLO se il session ID non e'
impostato nell'apposito cookie di sessione.
Utilizza questo codice in ognuna della pagine di test per visualizzare
il session_id corrente:
<?php 
session_start();
print("SID: " . session_name() . ' = ' . session_id());
?>
Per utilizzare le sessioni DEVI "avviarle" tramite session_start()
anche se utilizzi il trans_sid


 a propagare il SID tramite i tag definiti da url_rewriter.tags.
OPS, me ne sono accorto ora:
session.use_cookies On On
session.use_only_cookies Off Off
session.use_trans_sid Off Off
A quanto leggo, il trans_sid č disabilitato ma anche use_only_cookies lo č!
Allora le sezioni dovrebbero essere indipendenti dai cookies!
Come mai invece non me le tiene?


lucignolo ha scritto:

Rileggi attentamente la descrizione che il manuale ufficiale da di
use_only_cookies e di use_trans_sid.
Se l'utente ha disabilitato i cookie, il server NON ha abilitato il
trans_sid e l'applicazione non propaga "manualmente" il session ID, e'
logico che le sessioni non funzionino.


 (Hint: --enable-trans-sid)
ho controllato adesso con phpinfo:
Directive            Local Value  Master Value
session.auto_start       Off           Off
session.use_cookies      On            On
session.use_only_cookies Off           Off
session.use_trans_sid    Off           Off
Quindi, come mi regolo?
Se non leggo male, i cookies non dovrebbero essere determinanti.
Com'è che, allora, se sono disabilitati la sessione va a farsi friggere?


 logico che le sessioni non funzionino.
Ma use_only_cookies č a off!
Quindi dovrebbe fregarsene dei cookies, giusto?


 setting prevents attacks involved passing session ids in URLs. 
Impostare session.use_only_cookies ad off informa il PHP che puo'
utilizzare altri metodi oltre ai cookie per la propagazione delle
sessioni, nulla piu'.
Quello che sembra tu non capisca e' il funzionamento delle sessioni ed
il motivo per cui sia necessario che il client invii (tramite
GET/POST/COOKIE) al server l'ID di sessione.
Visto che tutte queste informaziono sono descritte in dettaglio sul
manuale ufficiale non intendo dilungarmi su questo argomento, ti basti
sapere che per mantenere la sessione, il client DEVE inviare al server
ad ogni richiesta un identificativo univoco che permetta al server di
caricare i dati della sessione. Se questo ID cambia ad ogni richiesta,
o non viene trasmesso, i dati della sessione NON possono essere
mantenuti.
Abilitando il trans-sid puoi fare in modo che il PHP si occupi della
riscrittura dei link/form etc. in modo da propagare le sessioni anche
quando l'utente ha disabilitato il supporto dei coockie di sessione.


Eccomi ancora qui.
Seguendo i vostri suggerimenti ho tentato la via dell'autenticazione via 
HTTP.
Credo che sia la strada giusta, ma mi manca ancora qualche dettaglio.
Ho creato questi files per fare alcune prove:
AUTH.PHP
<html>
<body>
<?php
   if (!isset($_SERVER['PHP_AUTH_USER']))
   {
     header('WWW-Authenticate: Basic realm="Il mio realm"');
     header('HTTP/1.0 401 Unauthorized');
     echo 'Messaggio da inviare se si preme il tasto Cancel';
   } else {
     echo "AUTH1<br>";
     if ($_SERVER['PHP_AUTH_USER'] = "tizio")
     {
     	echo "<p>Ciao socio.</p>";
     } else {
     	echo "<p>non sei iscritto</p>";
     }
   }
     echo '<br><a href="AUTH2.PHP">auth2</a>';
?>
</body>
</html>
e
AUTH2.PHP
<html>
<body>
<?php
   if (isset($_SERVER['PHP_AUTH_USER']))
   {
     echo "AUTH2<br>";
     echo "<p>Ciao {$_SERVER['PHP_AUTH_USER']}.</p>";
     echo "<p>Hai inserito {$_SERVER['PHP_AUTH_PW']}" .
          " come tua password.</p>";
   } else {
   	echo "Non ti sei loggato";
   }
     echo '<br><a href="AUTH.PHP">auth</a>';
?>
</body>
</html>
Risultato: se mi loggo come tizio tutto va ok, ma se mi loggo come caio
ecco che, tornando su AUTH.PHP, non mi fa più l'autenticazione in quanto 
$_SERVER['PHP_AUTH_USER'] esiste ed ' settata come "caio".
Ho tentato sia
$_SERVER['PHP_AUTH_USER']=""
che
unset($_SERVER['PHP_AUTH_USER'])
ma non ho ottenuto niente: $_SERVER['PHP_AUTH_USER'] rimane settata con 
"caio".
In che modo posso invalidarla qualora l'user non sia stato verificato?


 stato verificato?
Ti suggerisco di leggere il manuale ufficiale:
http://www.php.net/manual/it/features.http-auth.php


 quando l'utente ha disabilitato il supporto dei coockie di sessione.
Purtroppo non posso intervenire sul file php.ini, in quanto il fornitore
del servizio non me lo permette.
ma non demordo: in fin dei conti quello che mi interessa č poter sapere
se l'utente č loggato o meno, senza dover per forza "mettere i baffi 
alla gioconda". Ora sto considerando la via dell'autenticazione via 
HTTP, che mi pare piů percorribile.


 fornitore del servizio non me lo permette.
Non serve l'accesso al php.ini per abilitare session.use_trans_sid.
Ti suggerisco di leggere con attenzione il manuale ufficiale.
