No tak, te klase trzeba bedzie troche potestowac ;) Ze zniknal po wyczyszczeniu tabeli to normalne - ten blad sql wynikal, ze probowal ponownie dodac rekord o tym samym ID sesji. Czyli byles juz w bazie, a ten probuje dodac kolejny raz. Czemu?
No gdzies, w ktoryms warunku moze byc blad to fakt. Generalnie ciastko {prefix}ip okresla, ze user jest w systemie. Jezeli nie moze tego ciacha znalezc probuje dodac sesje w tabeli.
Co do tego ticketa to chodzilo mi cos w ten descen (procedura mysql):
CREATE PROCEDURE `SET_SESSION`(sessionId VARCHAR(32), sessionUser INT, sessionIp VARCHAR(15))
BEGIN
DELETE FROM coyote_session WHERE session_stop < (UNIX_TIMESTAMP() - 600);
SET @isSession = (SELECT session_id FROM coyote_session WHERE session_id = sessionId);
IF @isSession IS NOT NULL THEN
UPDATE coyote_session SET session_stop = UNIX_TIMESTAMP() WHERE session_id = sessionId;
ELSE
INSERT INTO coyote_session VALUES(sessionId, sessionUser, sessionIp, UNIX_TIMESTAMP(), UNIX_TIMESTAMP());
END IF;
END
Oczywscie, w uproszczeniu... ;)
Co do klasy user.class.php to w paru slowach idea jej dzialania:
W systemie dziala klasa User (zlokalizowana w lib/user.class.php), ktora odpowiada za obsluge uzytkownika.
Klasa wywolywana jest przed wykonaniem faktycznego kodu kontrolera. Jest to klasa statyczna, dostepna w calej aplikacji. Jest zainicjowanie nastepuje w pliku trigger/initialize.trigger.php (trigger). Wspolpracuje ona z tabela coyote_session, ktora przechowuje informacje o userach online, aktualnie zalogowanych w systemie.
W klasie najwazniejsza metoda jest metoda load(). W niej nastepuje odczytanie cookies znajdujacych sie na komputerze uzytkownika. System zapisuje 3 ciastka zwiazane z obsluga uzytkownika:
- coyote_sid - Unikalny 32 znakowy identyfikator sesji. Identyfikator jest unikalny dla kazdego uzytkownika
- coyote_ip - Ostatnie IP, z ktorego logowal sie uzytkownik
- coyote_data - Opcjonalnie, informacje o zalogowanym uzytkowniku (ID konta, haszowane haslo
Po odczytaniu informacji z ciastek, nastepuje uruchomienie garbage collectora. Jest on uruchamiany co jakis czas. Jak czesto? To reguluje parametr session_gc z pliku konfiguracji. Informacja o ostatnim uruchomieniu collectora, znajduje sie w tabeli coyote_config, w polu session_last_gc (jako timestamp). Garbage collector czysci nieaktywne sesje. W tabeli coyote_session kasowane sa rekordy, ktore stracily "waznosc". Dlugosc sesji regulowana jest polem session_length w pliku konfiguracji. W tabeli coyote_session, pod polem session_stop, znajduje sie informacja o godzinie i dacie ostatniej aktywnosci danego uzytkownika. Jezeli ten nie uczynil nic w przeciagu - dajmy na to - 10 min, system uznaje, ze opuscil on strone. Taki rekord nalezy skasowac.
Po uruchomieniu collectora, nastepuje uaktualnienie sesji. Czyli na podstawie SID (session ID) uaktualniamy w tabeli coyote_session czas ostatniej aktywnosci. W tym momencie oczytujemy rowniez informacje o uzytkowniku z tabeli coyote_user.
W przypadku, gdy sesja nie istnieje w tabeli coyote_session, nastepuje jej utworzenie w metodzie create() klasy User.
Informacje odczytane z tabeli coyote_session, coyote_user sa dostepne poprzez metode data(). Np. :
echo User::data('user_name'); // odczyt pola user_name
Albo skrocona werja tego zapisu:
echo User::data('name'); // system sam domysli sie, ze chodzi o pole user_name
Wiecej informacji o dzialaniu klasy, znajduje sie w pliku user.class.php. Tam kod jest opatrzony komentarzami.
