jak pamiątać logowanie na wielu stronach Opcje

[bobmail]

Witam

Nie mogę znaleźć adekwatnej sytuacji do mojej. Udało mi się stworzyć stronę logowania, odczytuję użytkowników z bazy danych, mogą sobie nadawać hasła do logowania, ale nie mogę przeskoczyć jednego problemu.

Skrypty pisałem w PHP wszystko jest lux, tylko po zalogowaniu użytkownik porusza się po wielu stronach html. Jak zrobić, że by informacja o zalogowanym użytkowniku mogła być przekazywana z podstrony na podstronę, bo w zależności od tego strona będzie miała różne zawartości. Nie jestem mocny w PHP programowałem trochę w Visual Basicu. Normalnie to zapamiętałbym jedną zmienną w pamięci i każda procedura mogłaby pobierać jej wartość i w zależności od niej pokazywać limitowane albo nie arkusze informacyjne. A jak zrobić żeby każda strona internetowa pobierała sobie informację o wartości jakiejś zmiennej (powiedzmy $idd), ze strony poprzedniej bez wypełniania jakichkolwiek pól lub formularzy?

[greycoffey]

@greycoffey

Zgadzam się z tobą w pełni,jednak myślę że nie jest to absolutne meritum.Zamiast sesji ,możesz użyć tabel temporalnych z bazach danych + metody get do wiązania danych między stronami.
example.com?name="Jacek"
select user,zalogowany from @TEMP_TABLE where name="Jacek"
If (zalogowany){
}else{
}

To taki drobny przykład.Nie jest powiedziane,że musisz użyć sesji żeby wiązać dane.Można np.tworzyć tabele temporalne których czas życia==czas zamknięcia browsera i wiązać dane przez querystring pomiędzy stronami tworzyć unikalne tokeny przy każdorazowym requeście.Inaczej mówiąc stworzyć całkiem odrębny mechanizm nieoparty na sesji ,zapisywany np.tabeli temporalnej.Coś ala, cookieless w asp.Net.

To są sesje (IMG:style_emoticons/default/wink.gif) Identyfikujesz na podstawie "name" które jest unikalnym kluczem tak samo jak zawsze SESSID, a przekazywanie przez $_GET to jedna z gorszych implementacji, cookie są stworzone do tego i lepiej oraz bezpieczniej wypełniają swoje zadanie. Jeśli chodzi o unikalne tokeny co request, to nawet lepiej można wykorzystać do ich przechowywania cookie (chyba, że to zabezpieczenie przed CSRF) - jeśli użytkownik odświeży stronę, będzie wszystko dobrze, a w twoim wypadku powinien mieć nowy token - tak samo, jak w sytuacji gdyby otworzył wiele kart).

Ja od jakiegoś czasu stosuję dwa identyfikatory sesji - jeden ma bardziej rygorystyczne zasady, krótszy czas życia, stosowany do wszelkich spraw, gdzie potzrzebna jest autoryzacja. Za to w drugim, przechowuje wszystkie dane, które muszą być przez dłuższy czas - m.in. token służący do automatycznego logowania.