![]() |
![]() ![]() |
![]() |
![]()
Post
#1
|
|
![]() Grupa: Zarejestrowani Postów: 338 Pomógł: 2 Dołączył: 4.03.2006 Skąd: Łódź Ostrzeżenie: (0%) ![]() ![]() |
Witam,
W PHP5 zaawansowane programowanie autorzy przedstawili mechanizm obslugi sesji, ktory trzymal zmienne w osobnej tabeli. Dzieki tezmu wydajnosc miala nieco wzrosnac. Takie rozwiazanie jednak ma pewna wade - zmienne pobierane za z sesji poprzez metody __get i __set, nie zaś $_SESSION['zmienna']; W chwili obecnie przysparza mi to więcej problemów niż mogłem to sobie wyobrazić. Jak Wy organizujecie session handlera? Jest sens dzielenia sesji na zmienne i info o sesji? Pozdrawiam, Adrian. |
|
|
![]()
Post
#2
|
|
![]() Grupa: Przyjaciele php.pl Postów: 742 Pomógł: 0 Dołączył: 14.12.2003 Skąd: Gdańsk, Trójmiasto Ostrzeżenie: (0%) ![]() ![]() |
poszukaj na tym forum o phiendzie2, sciagnij kod (w temacie w moim poscie jest link) i zobacz jak tam wygląda session handler (w HttpContext)
pozdrawiam |
|
|
![]()
Post
#3
|
|
![]() Grupa: Zarejestrowani Postów: 487 Pomógł: 7 Dołączył: 7.01.2004 Skąd: Warszawa Ostrzeżenie: (0%) ![]() ![]() |
Mi się podoba idea scope'ów. Polega ona na tym, że zależnie od rodzaju scope'a dane są utrwalane na określony czas - Application Scope = na stałe, Session Scope, Page Scope = sesja w obrębie strony oraz Request Scope.
-------------------- Łukasz Dywicki
Independent Java and open source software consultant. Blog - Java, OSGi, integracja oprogramowania.. |
|
|
![]()
Post
#4
|
|
![]() Grupa: Zarejestrowani Postów: 338 Pomógł: 2 Dołączył: 4.03.2006 Skąd: Łódź Ostrzeżenie: (0%) ![]() ![]() |
Jasne, mow mi wiecej
![]() |
|
|
![]()
Post
#5
|
|
![]() Grupa: Zarejestrowani Postów: 362 Pomógł: 0 Dołączył: 18.02.2004 Skąd: Knurów Ostrzeżenie: (0%) ![]() ![]() |
Cytat(Prph @ 2006-03-22 21:14:12) Jasne, mow mi wiecej ![]() Polecam więcej literatury traktującej o teorii programowania, wzorcach projektowych, aplikacjach biznesowych, itd. Może się tak wydawać, ale programowanie to nie tylko klepanie kodu na klawiaturze ![]() |
|
|
![]()
Post
#6
|
|
![]() Grupa: Zarejestrowani Postów: 338 Pomógł: 2 Dołączył: 4.03.2006 Skąd: Łódź Ostrzeżenie: (0%) ![]() ![]() |
Doskonale Cię rozumiem, ale ja ostatnio non stop siedze i czytam
![]() Nie miałbym problemów, jakbym sie nie uczepił rozwiązania przedstawionego w książce PHP5, Zaawansowane programowanie. Nadal uważam, że jest ono dobre, ale troche zakręcone. Napisałem więc raczej prosty session handler. Lekkie modyfikacje, zeby był wygodniejszy. Kod poniżej:
Przepraszam, że bez komentarzy, ale zamieszczam opis metod: Konstruktor: sprząta stare sesje. Wywoluje metodę _checkForActivesession a następnie uruchamia sesję. _checkForActivesession: sprawdza, czy użytkownik jest w trakcje sesji - na podstawie ciasteczka. Pobiera id sesji z ciastka i sprawdza w bazie czy jest jeszcze prawdziwa. Jezeli nie, usuwa ciastko. Jezeli sesja jest poprawna - odswieza jej czas metoda _updateSession. _sessionRead: wywoływana przez php. Sprawdza czy, jest sesja (jeżeli poprzednia metoda stwierdziała, że sesja jest poprawna, to także ustawiła id sesji). Jeżeli nie - tworzy nową za pomocą metody _createNewSession. Dalej pobiera dane sesji z bazy, ustawia id uzytkownika i inne dane, a następnie zwraca zmienne sesji. _sessionWrite: zapisauje zmienne sesji w bazie. login, logout, getUserObject to dodane przeze mnie metody, aby łatwiej zarządzać sesją ![]() CZekam na Wasze komentarze. Pozdrawiam, Adrian. |
|
|
![]()
Post
#7
|
|
![]() Grupa: Moderatorzy Postów: 1 566 Pomógł: 37 Dołączył: 14.05.2003 Skąd: Kraków ![]() |
Ja podzieliłem sesje na: User Sessions, czyli sesje jak każde inne, zapisuje się tam np. czy użytkownik jest zalogowany i Attributes Sessions, które przenoszą dane z modelu do akcji, która przekazuje je do widoku.
Prph - sesje jak każde inne, mysle, że połaczenie logowania z klasą sesji nie jest zbyt dobrym pomysłem. |
|
|
![]()
Post
#8
|
|
![]() Grupa: Zarejestrowani Postów: 338 Pomógł: 2 Dołączył: 4.03.2006 Skąd: Łódź Ostrzeżenie: (0%) ![]() ![]() |
A dlaczego?
Takie rozwiązanie jest wygodne. Jeżeli spojrzysz na to w ten sposób, że zalogowany user to przecież też sesja, tyle że lepsza ![]() Co prawda chciałem przeniesc logowanie do klasu Auth, ale pojawiłby się mały problem - info, czy użytkownik jest zalogowany powinno być trzymane w obiekcje sesji. Natomiast, jezeli logowala by klasa Auth to musialaby poinformowac obiekt sesji, ze user jest zalogowany. Jak dla mnie to jedyne rozwiazanie takie: $oSession->setUserLoggedIn(true); a to oznacza, ze metoda jest publiczna. Oczywiste jest, ze nie powinna byc publiczna :/ Jezeli przeniose login do klasy sesji to problem znika. A z racj, z jednak bardziej intuicyjne wydaje sie logowanie w klasie Auth, Auth posiada metoda login taka:
Pozdrawiam. } |
|
|
![]()
Post
#9
|
|
![]() Grupa: Zarejestrowani Postów: 122 Pomógł: 0 Dołączył: 23.01.2006 Ostrzeżenie: (0%) ![]() ![]() |
Po co pisac wlasna obsluge sesji? te wbudowane w php nie wystarcza?
|
|
|
![]()
Post
#10
|
|
![]() Grupa: Zarejestrowani Postów: 338 Pomógł: 2 Dołączył: 4.03.2006 Skąd: Łódź Ostrzeżenie: (0%) ![]() ![]() |
Cytat(Vomit @ 2006-03-25 13:33:53) Po co pisac wlasna obsluge sesji? te wbudowane w php nie wystarcza? No wystarcza wystarcza, a widziales kiedys na stronie takie cos jak: Obecni: 55 gości 12 zarejestrowanych użytkowników Takie coś jest możliwe dzięki własnej obsługi sesji. Poza tym - przechowywanie sesji w bazie wydaje się bardziej bezpieczne. |
|
|
![]()
Post
#11
|
|
![]() Grupa: Zarejestrowani Postów: 1 597 Pomógł: 30 Dołączył: 19.02.2003 Skąd: Tychy Ostrzeżenie: (0%) ![]() ![]() |
A mi sie wydaje, ze trzymanie sesji w bazie jest poprostu niepotrzebnym generowaniem zapytan SQL... na takie cos mozna sobie pozwolic w panelach administracyjnych, CRMach.
Pozatym nie trzeba miec wlasnej obslugi sesji by miec informacje ile osob jest zarejestrowanych, a ile gosci.. do tego wystarczy cos takiego jak napisal Ociu. Czyli mamy sobie klase np. CurrentUser, ktora odpowiada za uzytkownika, ktory chodzi po naszej stronie. -------------------- Zapraszam na mój php blog, tworzenie stron.
|
|
|
![]()
Post
#12
|
|
![]() Grupa: Zarejestrowani Postów: 338 Pomógł: 2 Dołączył: 4.03.2006 Skąd: Łódź Ostrzeżenie: (0%) ![]() ![]() |
No zgodze sie
![]() Ale wlasna obsluga sesji wydaje sie o wiele bardziej ulatwiac prace we frameworku. Mozna oczywiscie pominac wykorzystanie bazy. Ale dzieji niej, wszystko robi sie szybciej. |
|
|
![]()
Post
#13
|
|
![]() Grupa: Zarejestrowani Postów: 521 Pomógł: 0 Dołączył: 3.11.2003 Skąd: 3city Ostrzeżenie: (0%) ![]() ![]() |
@Prph:
1) Sesja, tak jak pisze Ociu, powinna być jednak oddzielona od uwierzytelniania. Bo jedno i drugie ma mało wspólnego. Można mieć przecież otwartą sesję nie będąc uwierzytelnionym (zalogowanym). Łącząc to bardzo się ograniczasz: - tworzysz obiekt User, mimo że klasa sesji nie ma co z tym obiektem zrobić i w efekcie zwraca puste nie-wiadomo-co - nie możesz wybierać źródła danych o użytkownikach (DB, pliki passwd, SMB i inne, LDAP, ...) - nie możesz rozbudować uwierzytelniania chociażby o przypisanie użytkownika do grup, bo wszystko jest hard-coded w klasie sesji 2) Bug: wcale nie jest powiedziane, że session_name() == 'PHPSESSID', a twój kod to zakłada. Poza tym, nie jest powiedziane, że sesje przekazywane są przez cookies, chociaż to akurat założenie ma chyba wiele kilka zalet. 3) Sprawdzanie poprawności sesji (tutaj: user agent) nie powinno odbywać się w klasie sesji. Takie rozwiązanie powoduje, że: - nie można tej funkcjonalności wyłączyć, gdy nie jest potrzebna - nie można jej rozszerzyć, gdy nie jest wystarczająca A przecież można zaprojektować to obiektowo, i dodawać do obiektu sesji obiekty "walidatorów", które sprawdzałyby poprawność i ew. zapisywały sobie user agent, referrer, IP lub inne dane potrzebne później do walidacji. Prosto, łatwo, obiektowo ![]() 4) Bardzo mi się za to podoba usuwanie niepotrzebnego cookie oraz przede wszystkim wywalanie sesji, gdy w cookie przyszedł session id nie istniejący w bazie. Domyślnie php (na plikach) tworzy wtedy nową sesję z podanym ID i dziura w bezpieczeństwie gotowa ![]() 5) Nie podoba mi się natomiast wywoływanie metody _checkForActiveSession() z konstruktora. To zdecydowanie za wcześnie. Po pierwsze, nie wiadomo, czy sesja na pewno będzie na tej stronie potrzebna (może obiekt był utworzony na zapas, a session_start() nigdy nie będzie wywołane?). Po drugie, nie wiadomo, jaka będzie nazwa sesji. Weźmy taki kod:
Powyższy kod zakończy się pewnie katastrofą. 6) W metodzie _readSession, po stworzeniu nowej sesji nie ma sensu odczytywać jej z bazy ![]() |
|
|
![]()
Post
#14
|
|
![]() Grupa: Zarejestrowani Postów: 338 Pomógł: 2 Dołączył: 4.03.2006 Skąd: Łódź Ostrzeżenie: (0%) ![]() ![]() |
No i to są bardzo dobre wskazówki - Hawk - dziękuję.
Co do PHPSESSID - wiedzialem o tym ![]() co do walidatorów - świetne rozwiązanie. Witam ponownie. Usiadlem dzisiaj do klasy sesji i zaczalem modyfikowac ja wedlug cennych uwag Hawka. Cytat "Można mieć przecież otwartą sesję nie będąc uwierzytelnionym (zalogowanym). Łącząc to bardzo się ograniczasz: - tworzysz obiekt User, mimo że klasa sesji nie ma co z tym obiektem zrobić i w efekcie zwraca puste nie-wiadomo-co - nie możesz wybierać źródła danych o użytkownikach (DB, pliki passwd, SMB i inne, LDAP, ...) - nie możesz rozbudować uwierzytelniania chociażby o przypisanie użytkownika do grup, bo wszystko jest hard-coded w klasie sesji" ad 1. - jak tworze pusty obiekt. Wedlug moich zalozen zawsze utworzony zostanienie obiekt uzytkownika. ad2. Ale to nie sesja chyba o tym powinna decydowac - tym zajmuje sie klasa User. Ona sama siebie uzupelnia danymi. ad3. Grupy do jakich zapisany jest uzytkownik przechowuje klasa uzytkownika. Dodam kod:
Pozdrawiam. Ten post edytował Prph 27.03.2006, 22:31:18 |
|
|
![]()
Post
#15
|
|
![]() Grupa: Zarejestrowani Postów: 521 Pomógł: 0 Dołączył: 3.11.2003 Skąd: 3city Ostrzeżenie: (0%) ![]() ![]() |
@Prph: Teraz sprawa się komplikuje, bo dochodzi jeszcze cała klasa User, a ja generalnie nie lubię klas o nazwie User
![]() ad. 1. Pisząc "pusty obiekt" miałem na myśli obiekt klasy User, nie trzymający żadnych informacji oprócz ID usera. Patrząc na konstruktor klasy User, wycofuję to zdanie. ad. 2. Tak, to nie sesja powinna decydować o tym, skąd wziąć "dane" użytkownika. Ale też nie powinna o tym decydować - o dziwo - klasa User. W twoim przykładzie jest to zaszyte częściowo w klasie sesji (sprawdzanie hasła i logowanie), a częściowo w klasie User (wyciąganie grup). Teraz kilka słów natury ogólnej: Klasa sesji, session handler, itd. powinny być minimalistyczne i nie robić nic poza utrzymywaniem i obsługą samej sesji, ponieważ wykorzystywane są często i wszelka dodatkowa funkcjonalność nas ogranicza. Przykładem jest twoja klasa sesji: umieszczając w niej kod sprawdzający poprawność hasła użytkownika pozbawiłeś się możliwości walidacji tego hasła na podstawie np. LDAP. Chcąć użyć tego nieszczęsnego LDAPa będziesz musiał napisać drugą klasę sesji, ze zmienioną funkcją do logowania. I w tym momencie okaże się, że najlepiej wyrzucić logowanie do osobnego obiektu i podmieniać w ramach potrzeb ![]() Klasy User, jak napisałem, nie lubię. Każda aplikacja może miec specyficzne dane, które związane są z użytkownikiem: e-mail, nr GG, avatar... Wspólnym mianownikiem jest tutaj konieczność uwierzytelniania użytkownika, a zatem login, hasło i - w zależności od przyjętego modelu uwierzytelniania - grupy, role, itd. To nie jest użytkownik! Najlepszym znanym mi słowem jest angielskie Credentials. Ewentualnie token, passport, itd. Ale umieszczanie w tej klasie funkcjonalności pobierającej listę grup jest złe, ponieważ znowu ograniczamy się do jednego źródła danych. Jeżeli grupy użytkownika też zaczniemy przechowywać na serwerze LDAP, będziemy musieli napisać klasę LDAPUser i używać zamiast zwykłego User. |
|
|
![]()
Post
#16
|
|
![]() Grupa: Zarejestrowani Postów: 338 Pomógł: 2 Dołączył: 4.03.2006 Skąd: Łódź Ostrzeżenie: (0%) ![]() ![]() |
Widze, ze Hawk chcialbys napisac narzedzie idealne :]
Ja pisze framework (bez obrazy) - nie dla Ciebnie, czy pana Kazia. On bedzie dla mnie. Kolejna sprawa - moze kiedys przeprawie go tak, zeby byl bardziej elastyczny. Moze jak wiecej sie naucze. I ostatnia - jak napisze framework, gdzie session handler bedzie maksymalnie podstawowy, wiekszosc klas takze maksymalnie podstawowa, to jak przyjdzie mi pisac jakas aplikacje na frameworku to okaze sie, ze zamiast skupic sie na kodzie mojej palikacji, to bede rozbudowywal po kolei kazda klase, bo one w koncu nie dzialaja :/ Pozdrawiam :] |
|
|
![]() ![]() |
![]() |
Wersja Lo-Fi | Aktualny czas: 26.06.2024 - 15:09 |