Pagina 1 di 2 1 2 ultimoultimo
Visualizzazione dei risultati da 1 a 10 su 18
  1. #1
    Utente di HTML.it
    Registrato dal
    Apr 2004
    Messaggi
    13

    $PHPSESSID e session_id()

    Salve a tutti.
    Vi espongo in breve il mio problema. Stò scrivendo una form d'iscrizione su + pagine. Per i dati ho optato per le sessioni. In locale il tutto funziona ok, senza propagare l'ID di sessione, ne con cookie. Leggendo il forum ho letto che è consigliato cmq propagare l'ID per aggirare problemi di utenti che con IE non attivano i cookie. Domande:
    1) è così cioè meglio propagare l'ID e non limitarsi alle sole $_SESSION con variabili raccolte all'occorrenza?
    2) $PHPSESSID non ho ben chiaro come funziona. Per trascinare l'ID avevo inizialmente assegnato session_id ad una normale $var mettendola negli url file1.php?sid=$sid ($var=session_id). Poi ho sostituito $var nell'url con $PHPSESSID senza assegnazioni ma non mi si propaga (test con mozilla e IE). Potete chiarirmi la differenza?
    3) per il log-out dalla sessione qual'è la sintassi migliore?
    grazie dell'attenzione e dei consigli che vorrete darmi.
    Chicco

  2. #2
    per la prima parte usa la tecnica di tutti .... no cookies? No party!

    la domanda 1) mi sfugge quasi tutta.

    la domanda 2) leggi le note nel file php.ini alla sezione [session] ti spiegano praticamente tutto in unione al manuale...

    la domanda 3) per il logout...
    codice:
    <?php
    session_start();
    $_SESSION = array();
    session_destroy();
    
    header ("location: ./pagina.php"); // => pagina non protetta
    exit;
    ?>
    sempre con riferimento al manuale sopra lincato.


    Il silenzio è spesso la cosa migliore. Pensa ... è gratis.

  3. #3
    Utente di HTML.it
    Registrato dal
    Apr 2004
    Messaggi
    13
    grz per la risposta.
    Se puoi darmi altro 2 minuti saresti cortese.

    la prima domanda era tesa a capire se la propagazione dell'ID è sempre obbligatoria che sia fatta tramite url che con cookie. Mi pare che tu abbia implicitamente detto si.
    Per il resto leggo figurati essendo un autodidatta nn ho fatto altro ed imparato da solo ma se non si hanno basi didattiche spesso nn è così facile.
    Il mio dubbo era capire, in due parole, la differenza fra estrapolare la sessione assegnata con session_id() e dichiararla con $PHPSESSID.
    Per il terzo punto grazie era quello ke volevo sapere.
    Aggiungere un session_unset()? è un doppione di $_SESSION = array();
    grazie dell'attenzione
    Chicco

    p.s.
    per la cronaca la mia è una multiform di iscrizione ad un sito, niente da proteggere, uso le sessioni solo per raccogliere i dati alla fine e buttarli su un DB MySQL.

  4. #4
    La sessione si svolge su due fronti. Da una parte il CLIENT dall'altra il server HTTP.

    Il server deve poter identificare il client e questo lo fa principalmente con il cookie di sessione. I parametri del cookie (nome, durata, valore) vengono impostati nel file di configurazione php.ini e verranno automaticamente applicati.

    Nel caso che il CLIENT dovesse avere l'accettazione del cookies disabilitata ci sono solo due vie: La prima e pure la piu' ovvia e' quella di non consentire il passaggio tra pagine protette obbligando ogni volta il CLIENT all'identificazione (come fa pure questo forum), l'altra e' quella di appendere al link il SID (identificatore di sessione) in modo tale da riconoscere comunque il CLIENT nella "continuazione" della navigazione entro pagine protette.

    Anche questa seconda possibilita' e' gestita tramite il file php.ini in modo automatico. Ma sara' necessario esporre l'id stesso della sessione nel link permettendo cosi' la facile copia e duplicazione di piu' utenti con lo stesso nickname. Basterebbe infatti copiare il link ed inviarlo via mail a qualche altro compare.

    Quindi come detto prima ... no cookie? no party. Non ti fidi di me? perche' mai dovrei fidarmi di te.

    Come detto prima la sessione si svolge su due fronti. Quindi ci sara' lato client un cookie di sessione con il nome, valore e la scadenza, dal lato server un file di sessione con il suo nome e la sua scadenza. Una sessione rimarra' valida entro i termini limite definiti da entrambe le parti.

    esiste poi la possibilita' di gestire le sessioni con il db invece che con file. Ma serviranno sempre cookie per riconoscere il client e la metodica leggermente diversa. (cfr. articolo di gm)

    Il silenzio è spesso la cosa migliore. Pensa ... è gratis.

  5. #5
    Utente di HTML.it
    Registrato dal
    Apr 2004
    Messaggi
    13
    grazie per la risposta, molto gentile.
    Non è chiarissimo (per me) ma mi hai dato una strada su cui studiare e lavorare.
    grz
    Chicco

    p.s.
    certo ke mi fido mica mi sono rivolto a qs forum a caso

  6. #6
    Utente di HTML.it
    Registrato dal
    Apr 2004
    Messaggi
    13
    sorry solo un'altra notazione.
    Prima ho letto frettolosamente e nel rileggere ipotizzi che il tutto, giustamente, sia dedicato alla protezione di pagine riservate o accessi con user e passw. Io le sessioni, come ti ho accennato nei precedenti post, le stò usando per fare una iscrizione, un mero inserimento di dati, su un mio sito; poi raccolto il tutto alla fine di 3 o 4 file.php lo metto su un DB MySQL.
    Volendola fare su + pagine (es.star.php nome e cognome start1.php via e città etec......) ho pensato che le sessioni fossero la strada più comoda e sicura tralasciando GET e POST.
    Spero di essermi spiegato senza annoiare.
    Pensi che questo possa cambiare in qualche modo il mio approccio alle sessioni e i miei dubbi con tue relative cortesi notazioni?
    grz ancora
    Chicco

  7. #7
    Originariamente inviato da piero.mac
    La prima e pure la piu' ovvia e' quella di non consentire il passaggio tra pagine protette obbligando ogni volta il CLIENT all'identificazione (come fa pure questo forum)
    Veramente no, il forum funziona anche a cookie disabilitati, passando il SID sull'URL.
    C'è l'apposita funzione nel pannello di controllo.

    Il mio consiglio, table, è quello di far funzionare il tutto in entrambi i casi, visto che il costo è praticamente zero.
    Se ci sono i cookie, usi i cookie, se non ci sono passi il SID sull'URL.

  8. #8
    sinceramente non considerei proficuo fare piu' pagine per aggiungere dati ad un form. Al limite una riproposta allo user dei dati inseriti per conferma. Personalmente se devo immettere dati alla seconda pagina lascio perdere l'iscrizione.

    Ovviamente le sessioni possono essere usate (personalmente ne faccio uso intenso) proprio per propagare/conservare dati tra pagine. Nulla cambia pero' nella necessita' di riconoscere il client.

    Rimango della mia idea. Vuoi iscriverti? abilita i cookie per il sito. Altrimenti ciccia.

    Puoi sempre impostare i dati di sessione come ti pare pagina per pagina con ini_set e passare il SID via URL. Per esempio nelle pagine di iscrizione in attesa di consolidare i dati, ma non lo farei mai per una connessione con iscrizione consolidata.



    Il silenzio è spesso la cosa migliore. Pensa ... è gratis.

  9. #9
    Originariamente inviato da skidx
    Veramente no, il forum funziona anche a cookie disabilitati, passando il SID sull'URL.
    C'è l'apposita funzione nel pannello di controllo.
    Il forum funziona a seconda dei cookie e a seconda se tu imposti il riconoscimento automatico. Quindi e' lo USER che acconsente al riconoscimento e non il forum.

    Piccola diversita' ma sostanziale nella forma.

    Il silenzio è spesso la cosa migliore. Pensa ... è gratis.

  10. #10
    Originariamente inviato da piero.mac
    Il forum funziona a seconda dei cookie e a seconda se tu imposti il riconoscimento automatico. Quindi e' lo USER che acconsente al riconoscimento e non il forum.
    Forse non mi sono spiegato, non parlo di riconoscimento automatico al primo ingresso (impossibile senza cookie), ma alla navigazione tra le pagine una volta che la sessione è inizializzata. E in questo funziona tranquillamente senza cookie, propagando il SID sull'URL.

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2024 vBulletin Solutions, Inc. All rights reserved.