Jak rozumiem, przeszedłeś do innej karty, ale aplikację dalej masz otwartą. Potem zamykasz tą otwartą kartę i wracasz do otwartej aplikacji. Możesz zapobiec otwieraniu linków ze swojej strony w innych oknach/kartach (też JS), więc nie otworzysz na raz n ajedno logowanie dwóch okien aplikacji. W czym problem?
Jakby ktoś nie wierzył, że to działa, tu kod (wiem, OFF TOPIC bo to JS): []
Wszyscy wiemy że to działa. Tylko Ty nie zauważasz, że to jest wkurwiające. Ile Ty widziałeś popularnych serwisów które takie techniki wykorzystują?
Już nie mówiąc o tym, że co bardziej idiotyczne antyspyware potraktuje taki kod uruchamiany na onunload jako wrogi i go po prostu zablokuje.
Dobra reguła programowania mowi by nie polegać na kodzie wykonywanym po stronie klienta. Ten kod jest po to by życie tego kto przegląda uczynić wygodniejszym, a nie życie programisty.
opuszczanie przez u źytkownika
Wszyscy wiemy że to działa. Tylko Ty nie zauważasz, że to jest wkurwiające. Ile Ty widziałeś popularnych serwisów które takie techniki wykorzystują?
No masz rację, bo onbeforeunload jest wkurwiające, jak każde powtarzające się pytanie 'czy jesteś pewien?'. Natomiast onunload już wkurwiające nie jest, bo można spokojnie zrobić własne rzeczy po cichu (wysłać AJAXem na serwer zmiany, wraz z informacją o opuszczeniu strony, żeby raz następny - niechby i po wciśnięciu 'Wstecz' - dać możliwość odzyskania stanu aplikacji i niezapisanych zmian). Już nie mówiąc o tym, że co bardziej idiotyczne antyspyware potraktuje taki kod uruchamiany na onunload jako wrogi i go po prostu zablokuje.
To jest chyba problem idiotyzmu antyspyware'u, w ciemno blokującego obsługę standardowych zdażeń - choć mógłbym się zrewanżować pytaniem, ile takich idiotycznych antyspyware'ów widziałeś :) Dobra reguła programowania mowi by nie polegać na kodzie wykonywanym po stronie klienta. Ten kod jest po to by życie tego kto przegląda uczynić wygodniejszym, a nie życie programisty.
Coś w tym jest. Z drugiej strony - idzie się przecież przekonać, czy kod po stronie klienta został wykonany, czy zablokowany. []
Jak masz mała stronę to na takie rzeczy sobie możesz pozwolić. Jak masz duża, to sobie nie pozwalasz bo zarżniesz bazę.
Nie w ciemno, ale na podstawie zbyt ogólnych założeń. I nie problem idiotyzmu, tylko klienta. Twojego klienta np. A więc i Twój :)
Norton, Kaspersky. Te dwa mają czasem naprawdę idiotyczne zachcianki. Np. nie pozwalał na wykonanie akcji "banowania" użytkownika w panelu administracyjnym, bo mu się coś w URL nie podobalo (strona była kompletnie bez javaskryptu na tym etapie - zwykły formularz + submit).
Inny "bajer" jaki spotkałem powodował np., że nie mogłem się zalogować do panelu pleska używając loginu "admin". Bo nie. Filtrowal całe zapytanie POST.
Ale po co? Jak trzeba czyścić np. sesje, to wstawiamy je do bazy i sprawa sprawdzenia co jest "zbyt stare" jest załatwiona i o wiele bardziej optymalnie jest to czyścić raz na godzinę niż "co wywołanie".
A jak się tak martwisz DOSem, to myślę, że prędzej wywalą Ci maszynę z powodu wysłania zbyt wielu requestów niż z powodu zapchania dysku. :)
Jak masz mała stronę to na takie rzeczy sobie możesz pozwolić. Jak masz duża, to sobie nie pozwalasz bo zarżniesz bazę.
Ale czemu? Przecież i tak musisz pamiętać stan aplikacji na serwerze, skoro, jak pisałeś, nie ma co polegać na wykonaniu kodu u klienta. Obsługa OnUnload może stworzyć kopię danych niezapisanych - czyli tak na prawdę jest kosztu maksymalnie 2*n. A jak się tak martwisz DOSem, to myślę, że prędzej wywalą Ci maszynę z powodu wysłania zbyt wielu requestów niż z powodu zapchania dysku. :)
Request przychodzi i odchodzi, ale dane, które przy nim generujesz zostają - i jeśli nie zadbasz o usuwanie na bieżąco, nim wybije godzina crona, może być w bazie już pierdyl, przepraszam, zylion rekordów :) []
Bo onunload to jest wywołanie nowego połączenia z bazą (a nie tylko samego zapytania), a nie ciągnięcie sesji poprzedniej. Czyli redukujesz sobie możliwą liczbę wejść znacząco.
W momencie gdy takie rzeczy robisz periodycznie przez cron, uniezależniasz się od ilości odwiedzin.
No ja Cię proszę.
Niech będzie, że niezapisane dane zajmują 4KB, czyszczenie jest co godzinę. Wolnego na dysku masz 4GB, bo byłeś skąpy i postawiłeś to na tanim hostingu.
Żeby tymi danymi zapełnić 1MB potrzebujesz 256 wywołania. Żeby zapełnić 1 GB potrzebujesz 262 144 wywołania. Przy 4GB mamy już 1 048 576 wywołania.
Żeby to obsłużyć musiałbyś dostać przez DOS ok. 290 wywołań _na sekundę_. Ponieważ byłeś skąpy, to nie wierzę że Twój tani hosting wytrzyma _fizycznie_ taki atak i maszyna po prostu przestanie na kolejne requesty odpowiadać, bo będzie zbyt zajęta.
Bo onunload to jest wywołanie nowego połączenia z bazą (a nie tylko samego zapytania), a nie ciągnięcie sesji poprzedniej. Czyli redukujesz sobie możliwą liczbę wejść znacząco. A widzisz - i o tym nie pomyśłałem. A *_pconnect() ? Żeby tymi danymi zapełnić 1MB potrzebujesz 256 wywołania. Żeby zapełnić 1 GB potrzebujesz 262 144 wywołania. Przy 4GB mamy już 1 048 576 wywołania.
Żeby to obsłużyć musiałbyś dostać przez DOS ok. 290 wywołań _na sekundę_. Ponieważ byłeś skąpy, to nie wierzę że Twój tani hosting wytrzyma _fizycznie_ taki atak i maszyna po prostu przestanie na kolejne requesty odpowiadać, bo będzie zbyt zajęta.
Faktycznie racja, przy założeniu niewielkiej ilości danych na sesję (4KB). Tak na prawdę, to jedyne, co budzi mój sprzeciw, to to, że mam sprzątać czymś innym, niż bałaganiłem (to odnośnie nawyków). []
pconnect nie jest taki wspaniały jak się wydaje, a przy wielu odwiedzinach i serwerze wielowątkowym Ci za przeproszeniem g* to da, bo połączeń do bazy będziesz musiał i tak mieć "trochę" otworzonych.
To jest dużo danych. 4 tysiące znaków. Każesz ludziom klepać wiecej jednorazowo? :)
Ograniczenia protokołu są ważniejsze niż nawyki programistyczne.