Zmienne sesji w Singleton Opcje

[tua1]

Witam

Pytanie trochę banalne, ale jak to jest z singletonami w PHP.
Wszyscy klienci strony korzystają z tego samego egzemplarza?

Chodzi mi dokładnie o to, czy mogę stworzyć rejestr potrzebnych danych sesji w innych częściach systemu, w którym będę przechowywał id, nazwę użytkownika itd.
Wiem, że mogę użyć po prostu $_SESSION, ale chcę żeby o tej tablicy wiedziała tylko klasa odpowiedzialna za autoryzację.

Czy mogę w takim przypadku użyć singletona jako reprezentacji klasy SessionRegistry, czy jest to kompletnie bezsensu bo dane te mogą zostać w każdej chwili podmienione przez inne żądanie?

[Mephistofeles]

Nie. Singleton jest globalny dla jednego wykonania skryptu.

[kfx]

jedynie sesja, zeby pamietalo request po requescie.
mozesz ew. dac w sesji tylko jakis klucz fragment danych, a np. klasa autoryzacji doklei sobie odpowiednie wartosci i odczyta odpowiednie dane i tylko ta klasa bedzie wiedziala gdzie ma czego szukac.

cos jednak musi w sesji byc...

[smentek]

Pytanie trochę banalne, ale jak to jest z singletonami w PHP.
Wszyscy klienci strony korzystają z tego samego egzemplarza?

Nie ma możliwości współdzielenia obiektów pomiędzy klientami. Każdy posiada oddzielny proces i oddzielne obiekty. Niezależnie czy obiekty budowane są na wzorcu Singletona czy nie.

Chodzi mi dokładnie o to, czy mogę stworzyć rejestr potrzebnych danych sesji w innych częściach systemu, w którym będę przechowywał id, nazwę użytkownika itd.
Wiem, że mogę użyć po prostu $_SESSION, ale chcę żeby o tej tablicy wiedziała tylko klasa odpowiedzialna za autoryzację.

Odwoływanie się bezpośredino do globalnej tablicy $_SESSION jest złą praktyką. Najlepiej stworzyć sobie obiekt odpowiedzialny za obsługę tej że tablicy. Najlepiej aby obiekt ten oparty był na wzorcu Registry lub podobnym.

[Crozin]

Odwoływanie się bezpośredino do globalnej tablicy $_SESSION jest złą praktyką.

A to niby dlaczego? Jakieś konkretne powody?

[smentek]

Powodów jest sporo. Jeden przykładowy:

Odwołując się do zmiennych o charakterze globalnym. (Zmienne w $_SESSION są to defakto zmnienne globalne) łatwo jest o przypadkowe błędy. Jednym z częściej występujących błędów przy kożystaniu z gołej tablicy $_SESSION jest nadpisanie wcześniej umieszczonych w niej zmiennych.

[PHP] pobierz, plaintext 
// Piszemy obiekt A i chcemy przechowywac go w sesji
// Wrzucamy obiekt do sesji.
$_SESSION['klucz'] = $objectA
 
// A po pararu miesiącach wracamy do kodu i piszemy inny obiekt B i także chcemy przechowywać go w sesji
$_SESSION['klucz'] = $objectB
[PHP] pobierz, plaintext 

Teraz mamy dwa obiekty które kozystają z tego samego klucza. Nie pamietaliśmy bowiem, że nazwa 'klucz' została wcześniej zarezerwowana.

Używając Registry możemy np. zrzucić na sam obiekt odpowiedzialność za to, aby nadał on sobie unikalny w skali systemu identyfikator. Tak, że wyżej opisywana sytuacjia nigdy nie będzie miała szansy wystąpić.

Możemy też ograniczyć wrzucane do sesji obiekty do określonych typów. Tak że nigdy nie wrzucimy do sesji obiektu, który nie miał sie tam znaleźć i który może wyskoczyć z niej kiedyś powodując problemy.

Itd. itp.

[Crozin]

session_set_save_handler - i masz po tych wszystkich problemach.

[smentek]

session_set_save_handler - i masz po tych wszystkich problemach.

Dzięki za link. Manuala PHP nigdy za dużo A teraz skorzystaj ze swojego linku i przeczytaj - przeczytaj dokładne - co sie za nim kryje. Jak to się ma do problemów związanych z sesją takich jak ten który opisałem wcześniej?

Ten post edytował smentek 26.03.2010, 20:58:29