Doszliśmy właśnie z embraced`em że tabela rr_session jest błędnie zdeklarowana: ip_sesji jest UNIQUE co uniemożliwia (a w każdym razie na pewno będzie sprawiac kłopoty) wejście na stronę 2 osób o takim samym adresie IP. Czyli np. 2 ludzie z tego samego osiedla nie mają szans się jednocześnie zalogować.
0
0
To samo w coyote_session, dodatkowo w coyote_session powinien chyba być założony indeks na session_id, a nie jest. Jakieś wnioski?
0
Hmm... wobec tego proponuje dodac do tego jeszcze ip. wew. i jakos kodowac aby powstala wartosc unikalna.
Teraz wyjasnienie po co to wszystko: niektorzy albo maja zablokowane cookie (w mniejszosci) albo moze sie zdarzyc ze serwis bedzie indeksowany przez robota.
Przy pierwszym wejsciu na strone ustawiane jest ID sesji (zapisywane jest w ciastku). Klasa session() jest napisana tak aby umozliwiala kontrole sesji bez ustawiania ciastka (tzn. SID bedzie przekazywane w _GET). I teraz jezeli ludek nie akceptuje ciastka to cookie nie zostanie wyslane ale rekord w tabeli rr_session zostanie utworzony.
Po kolejnym odswiezeniu strony system nie wykryje ciastka, ponownie zostanie wywolana metoda create(). Teraz system ponownie sprobuje dodac rekord do tabeli rr_session. Jezeli wykryje ze istnieje juz rekord w ktorym jest to samo IP, zmienia tryb przekazywania SID na _GET i od tej pory do linkow bedzie doklejony parametr $sid=
Chyba ze macie inne pomysly jak to rozwiazac?
0
Mozna skorzystac z jeszcze jednego rozwiazania. Na samym poczatku, przy pierwszym wejsciu usera na strone, jezeli nie zostanie wykryte jakiekolwiek ciacho przyjac tryb przekazywania SID poprzez parametr w tablicy _GET, czyli dokleic SID do linkow. Wtedy sprobowac umiescic ciacho.
Dopiero przy przeladowaniu strony i sprawdzeniu czy parametr SID z _GET rowna sie temu z ciastka, uznac, ze ciacha sa akceptowane i przechowywac SID w ciastku (zmienic tryb przekazywania sesji na ciastko).
0
Chyba znalazlem rozwiazanie. Jezeli zrobimy indeks w postaci primary key(session_user_id, session_ip). Uwzglednieniamy w ten sposob kilka osob z jednego adresu IP (o ile maja rozne user_id). Eliminujemy od razu SID gdyz nie jest juz potrzebne. Nie musimy rowniez umieszczac ciacha z id sesji, bo rozpoznajemy uzytkownika po ip oraz user_id. Roboty nie beda mialy ciastka z user_id czyli traktujemy je jako ANONYMOUS. Nie bedzie trzeba doklejac SID w linku (brzydko by wtedy taki zindeksowany link wygladal). Jakies pytania? :)
0
no tak, tylko co wtedy kiedy użytkownik ma wylączone cookie?
nie ma gdzie zapisać user_id, a po samym ip to nie bardzo :/
trzeba jakoś przekazywać dane..
0
Roboty nie beda mialy ciastka z user_id czyli traktujemy je jako ANONYMOUS.
To samo tyczy sie 'ludzkich' uzytkownikow - jesli nie ma cookie z user_id to traktujemy go jako ANONYMOUS, chyba logiczne?
0
No tak, ale jeśli komuś nie działają cookie? to co ma być ANONYMOUS?
tu jest wlasnie problem...
0
To niech zainstaluje przeglądarkę nowszą niż 5 letniego dziadka. Bez przesady, że dla 1% zatwardziałych maniaków staroci cała ekipa RR będzie się głowiła jak takim dogodzić.
A jeśli ma nową przeglądarkę ale specjalnie wyłączył ciacha to również musi liczyć się z konsekwencjami. Po to wynaleziono ciacha aby z nich korzystać.
To tyle w tej kwestii.
0
Nie no, logowanie nie bedzie mozliwe dla osob, ktore nie maja oblugi ciastek. Chodzi o to, zeby dla takich osob (czy wlasnie botow) nie powstawaly za kazdym razem nowe sesje w bazie, bo system nie potrafi znalezc ciastka z ID sesji.
Teraz jezeli ustawimy PRIMARY KEY dla session_user_id i session_ip to dwie osoby korzystajace z tego samego IP bedace anonimowe beda korzystaly z tej samej sesji.
W moim przypadku (IP jest u mnie zmieniany co pare minut) zamiast uaktualniania starej sesji, tworzona bylaby nowa gdyby zastosowac rozwiazanie bazujace na wykrywaniu IP.
Jezeli chodzi o brzydkie linki, ktore zostana zindeksowane przez roboty, to prawda... ale dla nas chyba to nie ma znaczenia?