Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: [PHP]bezpieczne logowanie
Forum PHP.pl > Forum > Przedszkole
gitbejbe
Witam. Mam pytanie czysto teoretyczne tak więc nie będę wklejał niepotrzebnie kodu.
Przeleciałem już kilkanascie stronn na tym forum w poszukiwaniu pomocy, również w googlasie nie jest łatwo odzszukac jednoznaczej odpowiedzi na mój problem.

Muszę zrobić jak najbezpieczniejsze logowanie. Robie duży projekt, w którym w gre już wchodzą pieniądze na kontach użytkowników.

Dlatego tez mam pytanie odnośnie logowania, najpierw zaczne od tego co zrobiłem.

w moim formularzu, mozna logowac sie poprzez email/login i hasło

-najpierw pobieram dane i nakładam na nie "htmlspecialchar"
-sprawdzam później poprzez wyrażenia regularne w php, czy oba pola posiadają dozwolone znaki. Dla loginu przewiduje tylko litery, cyfry i znaki używane w mailach. Dla hasła tylko cyfry i litery.
- jeśli jest ok, sprawdzam, czy ktoś taki istnieje - po loginie albo emailu (poprzez funkcje sprawdzam kto co podał do logowania)
- sprawdzam tylko czy istnieje takie ID w bazie i czy konto jest aktywne, jeśli tak pobieram tylko ID.
- jeśli istnieje, tworze sesje i narazie to wszystko

co do trzech pierwszy punktów, chce jeszcze dodać dla hasła znaki specjalne dla zwiększenia siły i wymóg w rejestracji do stosowania znaków specjalnych.
mam dodaną również blokadę logowania dla IP na 15min jeśli w ciagu 5minut logował się bez powodzenia 20razy.
Hasła są pięknie kodowane w sh1 i solone tak, że nie ma bata na złamanie.

do sesji dodaje tylko ID użytkownika na zasadzie $_SESSION['identyfikator'] = $row['id']. No a póżniej sprawdzam czy istnieje taka sesja na odpowiednich stronach

no i teraz odnośnie tworzenia sesji. Tutaj jest mój dylemat. Nie mogę sobie pozwolić na ataki, gdzie ktoś mógłby wejść na czyjeś konto i np zażądać wypłaty jego pieniędzy.
Naczytałem się, że najbezpieczniej jest użyć do tego ciastek, gdzie do takiego ciastka wrzucam np te ID z sesji i sprawdzam za każdym razem czy sesja i ciastko są takie same. Wolałbym jednak nie bawić się w ciastka ze względu na to, że każdy ma prawo je blokować w przeglądarce.

Wytłumaczcie mi jeszcze, jeśli zna ktoś mój identyfikator sesji czyli dla $_SESSION['identyfikator'] jest nią string "identyfikator", to co wtedy ? jakiś przykład ?

Jak ktoś ma z was dobre doświadczenie odnośnie bezpieczeństwa sesji, prosze o pomoc merytoryczną jak najlepiej się zabezpieczyć. Tylko prosze prostym językiem i łopatologicznie bo jeszcze nigdy takich zabezpieczeń dla sesji nie robiłem.
Damonsson
Jest milion artykułów o bezpieczeństwie sesji. Nikt tutaj Ameryki nie odkryje i koła nie wynajdzie.
Sephirus
1. Logowanie - email i hasło - dla bezpieczeństwa zawsze podawaj jeden komunikat - "Podano niepoprawne dane" - nie podawaj czy był zły e-mail, czy hasło itp.
2. Trzymanie hasła w bazie - użyj jakiegoś algorytmu opartego o bluefish i podobne z dużą liczbą iteracji i długim czasem generowania skrótu, dodaj długi SALT (zerknij na PHPass) SHA1 to już przeżytek nie oszukujmy się - jesli w grę wchodzi kasa - lepiej poszukać czegoś mocniejszego.
3. Samo hasło - masz wymogi Giodo zapoznaj się z podstawowymi (8 znaków) i mocnymi (12 znaków) - możesz dodać też algorytm sprawdzania podobieństwa hasła do innych danych użytkownika (mail, login, imie itp) i blokować zbyt podobne (poczytaj o tym - znajdziesz coś napewno)
4. Blokada logowania po IP jest bardzo nieprzyjemna - polecam raczej np. 3 próby, potem CAPTCHA, potem dopiero blokada na określony czas.
5. Jakiś podstawowy mechanizm "utrudniający" logowanie BOTOM itp (tokeny itp)


Co do sesji to panikujesz zupełnie biggrin.gif

Twoje podejście jest prawidłowe czyli: Logowanie -> zapis ID klienta w sesji w celu poznawania go.

Sesja standardowo działa tak, że ma swój session_id po którym jest poznawana. Jest on zapisywany w ciastku. Taki mechanizm jest bezpieczny dopóki nikt nie ukradnie nam ciastka. To znaczy są dwa komputery - twój i włamywacza - Ty się logujesz - włamywacz zabiera ciastko i ustawia sobie i bach! jest zalogowany na Ciebie. Sytuacja ta jednak jest ciężka do ogarnięcia ale można się bardzo łatwo zabezpieczyć przed nią. Przy logowaniu zrób tak:

user się loguje, sprawdzasz dane - są ok - więc:
- dodajesz ID usera do sesji,
- pobierasz id sesji (session_id) i mieszasz go dowolny algorytmem znanym tylko Tobie (np MD5 z ID sesji, IP, USER-AGENT, ID_usera) i zapisujesz w ciasteczku pod np. zmienną AUTH
- po wejściu na stronę robisz łatwy skrypcik, który sprawdza czy w sesji jest id_user i jeśli tak to robisz jeszcze raz taką MD5kę i porównujesz ją z zawartością ciasteczka AUTH jeśli się zgadza jest ok - jeśli nie - masz WŁAM i możesz go zablokować - proste? Żeby włamywacz dał radę się włamać musiałby mieć dokładnie to samo IP, dokładnie tą samą wesję przeglądarki itd..

Co do pytania ostatniego to nie ma możliwości znalezienia tego co masz w kodzie (o ile się nie włamie na serwer) więc nieinteresuje Cię zupełnie to co trzymasz w sesji bo jest to wyłącznie lokalnie na serwerze (sesji nie ma w przeglądarce - tam jest tylko w ciastku zapisany identyfikator sesji).

Mam nadzieję że Ci to pomoże - poczytaj więcej o tych sesjach wink.gif
gitbejbe
@Sephirus

I tego właśnie potrzebowałem, dzięki za rzetelne podejście do tematu : )

co do ciastka i blokady, to zamiast może solić danymi o przeglądarce i IP to może lepiej wygenerowac jakiś token dla sesji ? czyli sesja składałaby się z z ID i tokenu. Ciastko to byłby hash md5 czy tam sh1 z solą id oraz token. Zamiast blokować to może poprostu usuwać sesje i przekierowywać na strone glówną ? nie chciałbym, aby ktoś był niechcąca poszkodowany.

Mógłbyś mi jeszcze wytłumaczyć sens regenerating_session_id ?

a i czaje z tym kodowaniem. Czyli jak ktoś nawet przechwyci jakoś ciastko z id_sesji, to zobaczy tylko hash, którego porpostu nie odkoduje więc nie będzie wiedział co w nim jest. To rozwiązuje problem podszycia pod każdą inną osobę, lecz jeśli ma hash konkretnej sesji w ciastku, to i tak może go on wykorzystać do włamania? Skoro na stronie sprawdzam hash ciastka, a włamywacz go posiada, to tak czy siak może się on włamać na to konkretne konto ?
Sephirus
Cytat
co do ciastka i blokady, to zamiast może solić danymi o przeglądarce i IP to może lepiej wygenerowac jakiś token dla sesji ? czyli sesja składałaby się z z ID i tokenu. Ciastko to byłby hash md5 czy tam sh1 z solą id oraz token. (...)


Oj nie - nie do końca rozumiesz - to nic nie da.

Rozważ taką sytuację:

Włamywacz na chwilę siada do komputera ofiary, kopiuje wszystkie ciastka i ucieka. Wraca do siebie, wrzuca ciastka do swojej przeglądarki i odpala stronę. Jeśli użytkownik jest poznawany tylko po hashu/id sesji z ciastka to gościu już ma dostęp - niezależnie od tego jakiego jakiego tokenu i kombinacji funkcji skrótu użyjesz. Po wejściu na stronę sprawdzisz ten hash z ciastka/ id sesji i wszystko się będzie zgadzać - masz włam.

Sytuacja druga (moja propozycja):

Dokładnie to samo - kradzież ciastek i odpalenie strony u siebie. Teraz włamywacz dodał dwa ciastka - jedno z id sesji a drugie AUTH. System sprawdza że sesja posiada id_user więc nastepuję sprawdzenie ciastka AUTH. Generowany jest HASH na podstawie MD5 z danych IP/przeglądarki i id sesji. Włamywacz korzysta z innej przeglądarki lub ma inne IP. Hash więc nie jest taki jak zapisany w AUTH - wyświetlamy - SPADAJ WŁAMYWACZU smile.gif

Cytat
Zamiast blokować to może poprostu usuwać sesje i przekierowywać na strone glówną ? nie chciałbym, aby ktoś był niechcąca poszkodowany.


Słusznie smile.gif ja nie radzę też blokować w takiej sytuacji. Wylogowanie byłoby chyba najlepszym rozwiązaniem. Możesz oczywiście połączyć to z bazą danych i monitorować wszystko. Są takie systemiki i wcale nie trudne do napisania. Wystarczy zapisywać przy każdym logowaniu usera ID sesji i jego ID gdzieś do bazy - w ten sposób masz info które sesje są aktywne i poprawne. Zobacz taką sytuację:

Klient loguje się z domu. Zapisujesz w tabeli Id usera i id sesji i czas kiedy się zalogował. Jego kolega loguje się w pracy na jego konto. Podaje dane i zostaje zalogowany - znowu dodajesz wpis do bazy. Widzisz już w niej że dany user jest zalogowany z dwóch różnych miejsc ale poprawnie - może to być atak ale nie musi (jak w tym przypadku własnie nie jest). W każdej chwili możesz pokazać użytkownikowi kiedy i skąd się logował (jak dodasz do tego wpisy historyczne). Dzięki temu user będzie widział że jego kolega bez pozwolenia logował się z pracy na przykład. No i sytuacja najgorsza - ktoś skopiował (np zły kolega z pracy) ciastka tego gościa z pracy i wrzucił do siebie. System wykryje że coś jest nie halo - bo IP lub UA nie będzie się zgadzało. W tym miejscu możesz poinformować userów na obu aktywnych sesjach o tym, że nastąpiła próba włamania z danego IP itp. I kolega z pracy ochrzani tego włamywacza a klient kolegę że dał mu pobrać ciastka... tongue.gif

Oczywiście samo sprawdzanie po IP / User-agent jest dobre w zamyśle że komputer włamywacza nie jest podpięty pod ten sam switch i nie ma tej samej przeglądarki smile.gif ale taka sytuacja już jest naprawdę bardzo rzadka.

Cytat
a i czaje z tym kodowaniem. Czyli jak ktoś nawet przechwyci jakoś ciastko z id_sesji, to zobaczy tylko hash, którego porpostu nie odkoduje więc nie będzie wiedział co w nim jest. To rozwiązuje problem podszycia pod każdą inną osobę, lecz jeśli ma hash konkretnej sesji w ciastku, to i tak może go on wykorzystać do włamania? Skoro na stronie sprawdzam hash ciastka, a włamywacz go posiada, to tak czy siak może się on włamać na to konkretne konto ?


No to opisałem właśnie wyżej wink.gif - jeśli będzie to tylko ciastko z sesison_id to włam po jego zdobyciu jest nieunikniony (chyba że zastosujesz jakąś metodę ochrony - przykładowo moją)

Cytat
Mógłbyś mi jeszcze wytłumaczyć sens regenerating_session_id ?


Regenerowanie id sesji jest dobre jako zabezpieczenie ale kłopotliwe. Działa to tak, że co każdy (lub co któryś) request do strony id sesji jest tworzone na nowo i przypisywane. Traci się to stare ID sesji przez co jak ktoś je skopiuje i użyje to nie zaloguje się. Ale... tak jak pisałem to kłopotliwe - za każdym razem tracisz całą sesję i musisz ją przepisywać - jest to niewygodne. Poczytaj o tym więcej - ja unikam tego rozwiązania bo jest ciężkie w kontroli - jeśli chciałbyś zrobić na tym coś zaawansowane jak system monitoringu to wiążę się z tym dużo pracy / zmian / kopiowania sesji do sesji / zapytań do bazy - odradzam.
gitbejbe
super : )

mógłbyś podpowiedzieć jeszcze czy taki skrypt na sprawdzanie IP i przeglądarki starczy ?
  1. function spr_IP()
  2. {
  3. if (isset($_SERVER['HTTP_X_FORWARDED_FOR'])) { $ip = $_SERVER['HTTP_X_FORWARDED_FOR']; }
  4. else { $ip = $_SERVER['REMOTE_ADDR']; } return $ip;
  5. }
  6.  
  7. function spr_przegladarke()
  8. {
  9. $brow = strtolower($_SERVER['HTTP_USER_AGENT']);
  10. if(strpos($brow, 'firefox') !== false) { $nazwa = 'Firefox';}
  11. elseif(strpos($brow, 'opera') !== false) { $nazwa = 'Opera';}
  12. elseif(strpos($brow, 'msie') !== false) { $nazwa = 'Internet Explorer';}
  13. elseif(strpos($brow, 'chrome') !== false) { $nazwa = 'chrome';}
  14. else { $nazwa = 'Inna'; }
  15. return $nazwa;
  16. }
  17.  
  18. echo '<br>'.spr_IP();
  19. echo '<br>'.spr_przegladarke();


i jeszcze jedno. A jak klient ma wyłączone ciastka, to co wtedy z logowaniem ?

nie mogę zrobić tego samego co z ciastkiem ale tylko dla sesji ? czyli sesje też walnąć hashem i tylko ja sprawdzać i nie bawić się w ciastka
EDIT
w sumie bez sensu, bo jak później sprawdzę tą sesje x)
ber32
Witam. Funkcja spr_ip() sama w sobie jest niebezpieczna.

  1. function ip()
  2. {
  3. if(isset($_SERVER["HTTP_X_FORWARDED_FOR"])) // wartość superglobalnych
  4. {
  5. $tt = $_SERVER["REMOTE_ADDR"]." proxy"; /// ip proxy niby
  6. }else{
  7. $tt = $_SERVER['REMOTE_ADDR'];
  8. }
  9. return $tt; // ." ".$tt_g
  10. }


lepiej tak oneeyedsmiley02.png
gitbejbe
właśnie, jak to jest z tym IP ? ten skrypt może byc wadliwy ? tzn nie zawsze pokaże prawdziwe IP ? tzn tak czy siak coś zwróci...

ok, jeszcze ostatnie pytanie odnośnie już ciastek
najpierw ustawienie ciastka:
  1. //logowanie
  2. if(wszystko dobrze z formularzem)
  3. {
  4. $cookie_hash = cookie_hash($row['login'],spr_IP(),spr_przegladarke());
  5. $_SESSION['login'] = $row['login'];
  6. setcookie('user_cookie', $cookie_hash, time() + 30 * 86400);
  7. }

no i teraz funkcja sprawdzające sesje i ciastko przy każdej odpowiedniej stronie
  1. function session_check()
  2. {
  3. if(isset($_SESSION['login']))
  4. {
  5. if(!$_COOKIE['user_cookie']){ header("Location: wyloguj.php"); }
  6. else
  7. {
  8. $spr_salt = sha1($_SESSION['login'].spr_IP().spr_przegladarke());
  9.  
  10. if($_COOKIE['user_cookie'] == $spr_salt) { return true;}
  11. else { header("Location: wyloguj.php"); }
  12. }
  13. }
  14. }


dodam jeszcze, ze przy wylogowaniu usuwa sesje i ciastko.
Sephirus
Zamotałem się z tym Twoimi pytaniami ale po kolei smile.gif

1. Co do IP to poprawka ber32 jest w sumie ok bo HTTP_X_FORWARDED_FOR potrafi zwracać różne kosmosy - trzeba by to było ładnie obsłużyć a szczerze nie wiem czy jest sens smile.gif
2. Co do funkcji spr_przegladarke to przegiales - nie wykrywaj co to za przeglądarka w taki sposób - uproszczasz skrypt...

Jeśli koleś wejdzie z IE 10 to wystarczy IE 9 i już system się nie połapie. Najwięcej danych jest w $_SERVER['HTTP_USER_AGENT'] i to powinieneś zapisać a nie po przetworzeniu. Najlepiej zrobić tak:

  1.  
  2. function generateAuthHash() {
  3. if(!isset($_SERVER['HTTP_USER_AGENT'])) return false; // jeśli nie ma USER_AGENT to na bank mamy request nie z przeglądarki
  4.  
  5. $ip = ip();
  6. $browserId = $_SERVER['HTTP_USER_AGENT'].(isset($_SERVER['HTTP_ACCEPT_LANGUAGE']) ? $_SERVER['HTTP_ACCEPT_LANGUAGE'] : 'empty_accept_language_string';
  7.  
  8. return sha1('salt1'.$ip.'salt2'.$browserId.'salt3');
  9. }
  10.  
  11. // przy logowaniu:
  12.  
  13. $hash = generateAuthHash();
  14. if(!$hash) die('Użyj przeglądarki cfaniaczku!');
  15.  
  16. setcookie('AUTH',$hash); // nie podawaj czasu - ciastko będzie kasowane razem z ciastkiem sesji
  17.  
  18. // przy sprawdzaniu czy zalogowany (idea):
  19.  
  20. if(isset($_COOKIE['AUTH'])) {
  21. $hash = generateAuthHash();
  22. if(!$hash) die('Użyj przeglądarki cfaniaczku!');
  23.  
  24. if($hash != $_COOKIE['AUTH']) die('Coś kombinujesz koleś!');
  25.  
  26. echo 'witaj ;)';
  27. }
  28.  


Cytat
dodam jeszcze, ze przy wylogowaniu usuwa sesje i ciastko.


Super ale mam nadzieję, że tylko po prostu usuwasz ciastka danemu gościowi z przeglądarki - tak żebyś nie usuwał fizycznie sesji - bo wylogujesz normalnie zalogowanego usera wink.gif
gitbejbe
wylogowanie właśnie u mnie wyglada tak :

session_destroy();
setcookie('user_cookie', $cookie_hash, time() - 30 * 86400); //odejmuje czas co skutkuje wygaśnięciem

i jak : |?


- no i chyba ostatnia rzecz: co wtedy gdy ktoś ma zablokowane ciastka w przeglądarce ? jest jakaś metoda na sprawdzenie tego ?

ps: i po za tym to wielkie dzięki za pomoc ! gdyby była taka możliwość wynagrodziłbym w browarach !
mlawnik
Evercookie może pomoc.
gitbejbe
Evercookie to zbędne rozwiązanie do ciastek, które służą tylko do sprawdzenia sesji.

Ponawiam pytanie, jeśt jakaś możliwość aby sprawdzić czy użytkownik ma zablokowane ciastka w przeglądarce ? jeśli mam miec system logowania oparty na sesji i ciastku, to przy blokadzie ciastek w przeglądarce użytkownik za cholere nie będzie mógł się zalogować... Macie na to jakiś pomysł ?
kosmaty_zab
Ja to zrobiłem tak (na podstawie pracy użytkowników wyżej)
logowanie
  1. if (empty($_SESSION['login']) || empty($_SESSION['password'])){
  2. @$_SESSION['login'] = trim($_POST['login']);
  3. @$_SESSION['password'] = trim($_POST['password']);
  4. }
  5. //logowanie
  6. if (empty($_SESSION['login']) || empty($_SESSION['password']))
  7. include('logowanie.html');
  8. else{
  9. if(sprawdzenie_sesji(@$_COOKIE['AUTH'])){
  10. echo "Witaj, <b>".$_SESSION['login']."</b>"." "."<a href=\"wyloguj.php\">[Wyloguj]</a><br><br>";
  11. echo "<a href=\"admin_panel.php\">Panel Administratora</a>";
  12. }
  13. elseif(logowanie_sprawdzanie ($_SESSION['login'], $_SESSION['password'])){
  14. $hash = generateAuthHash();
  15. if(!$hash) die('Użyj przeglądarki cfaniaczku!');
  16. setcookie('AUTH',$hash); // nie podawaj czasu - ciastko będzie kasowane razem z ciastkiem sesji
  17. echo "Witaj, <b>".$_SESSION['login']."</b>"." "."<a href=\"wyloguj.php\">[Wyloguj]</a><br><br>";
  18. echo "<a href=\"admin_panel.php\">Panel Administratora</a>";
  19. }
  20. else{
  21. echo "Podane hasło lub login jest nieprawidłowe. Proszę spróbować ponownie.";
  22. include('logowanie.html');
  23. }
  24. }
  25.  


i niezbędne funkcje
  1. function logowanie_sprawdzanie ($login, $password){
  2. @ $db = mysqli_connect('localhost', 'nazwa użytkownika', 'hasło', 'nazwa bazy');
  3. if(!$db){
  4. echo "Połączenie z bazą danych nie powiodło się.";
  5. exit();
  6. }
  7. $zapytanie = "select login, password from admin where login='".$login."' and password='".sha1($password)."'";
  8. $wynik = mysqli_query($db, $zapytanie);
  9.  
  10. $ile_znalezionych = mysqli_num_rows($wynik);
  11. if ($ile_znalezionych!=1)
  12. return false;
  13. elseif ($ile_znalezionych=1)
  14. return true;
  15.  
  16. mysqli_close($db);
  17. }
  18.  
  19. function ip(){ //sprawdzanie i wyślatlanie adresu ip
  20. if(isset($_SERVER["HTTP_X_FORWARDED_FOR"])) // wartość superglobalnych
  21. $tt = $_SERVER["REMOTE_ADDR"]." proxy"; /// ip proxy
  22. else
  23. $tt = $_SERVER['REMOTE_ADDR'];
  24.  
  25. return $tt; // ." ".$tt_g
  26. }
  27.  
  28. function generateAuthHash() {
  29. if(!isset($_SERVER['HTTP_USER_AGENT']))
  30. return false; // jeśli nie ma USER_AGENT to na bank mamy request nie z przeglądarki
  31. $ip = ip();
  32. $browserId = $_SERVER['HTTP_USER_AGENT'].isset($_SERVER['HTTP_ACCEPT_LANGUAGE']) ? $_SERVER['HTTP_ACCEPT_LANGUAGE'] : 'empty_accept_language_string';
  33.  
  34. return sha1('$@#FFE$%'.$ip.'@#$ASDAYJ$%!'.$browserId.'!@#%@$#DWD#$@%');
  35. }
  36.  
  37. function sprawdzenie_sesji($a){
  38. if(isset($a)){
  39. $hash = generateAuthHash();
  40. if(!$hash)
  41. return false;
  42. if($hash != $a)
  43. return false;
  44. }
  45. else
  46. return false;
  47.  
  48. return true;
  49. }


wylogowanie
  1. setcookie('AUTH',' ', time()-3600);
  2.  
  3. header("Refresh: 0; url=index.php");
gitbejbe
@kosmaty_zab, dałem plusa bo się trochę napracowałeś ale Twój skrypt niczego dla mnie nie wniósł... na moje potrzeby to co przedstawiłeś to o 300% za mało. Mam już działający skrypt, który jest silnie rozbudowany i zabezpieczony. Mi chodzi tylko o teorie. Napisałem, że pierwszy raz robie logowanie na ciastkach z nie, że w ogolę robię pierwszy raz logowanie.

Ciągle ponawiam pytanie:
Cytat
Ponawiam pytanie, jest jakaś możliwość aby sprawdzić czy użytkownik ma zablokowane ciastka w przeglądarce ? jeśli mam miec system logowania oparty na sesji i ciastku, to przy blokadzie ciastek w przeglądarce użytkownik za cholere nie będzie mógł się zalogować... Macie na to jakiś pomysł ?
cykcykacz
Jeżeli chodzi o sprawdzanie czy przeglądarka ma włączone ciastka:

http://nik.chankov.net/2010/01/16/detectin...abled-with-php/
http://www.developertutorials.com/tutorial...me-050526-1149/
Sephirus
Co do pytania smile.gif

Odpowiem tak:

W obecnym czasie normalni użytkownicy nie blokują ciastek na stronach. Procent tych, którzy by coś takiego zrobili jest baaardzo malutki. Jeśli zaś w grę wchodzą pieniądze to większość z tych użytkowników to tak naprawdę byłyby nieskładne kombinacje prób włamywania. Najprostsze i najbardziej rozpowszechnione jest logowanie na ciastkach - istnieje jeszcze możliwość użycia trans_id i przesyłania id sesji jako parametr GET - jednakże z bezpieczeństwem ma się to na bakier (niektórzy potrafią wysłać komuś link do czegoś i ten ktoś od razu jest na nich zalogowany).

W paru słowach - nic nie wykrywaj, nic nie rób - jak ktoś nie będzie miał włączonych ciasteczek to jego problem - serio. Możesz ewentualnie dać info przy logowaniu bądź gdzieś na stronie że serwis korzysta z ciastek wink.gif
gitbejbe
@cykcykacz

Dzięki za linki. Rozwiązanie jest tak proste, że dziwie się, że na to nie wpadłem : )

@Sephirus

to, ze ludzie nie blokują ciastek to rzecz tak pewna jak to, że Tusk to złodziej (;p), ale jednak jest też % osób, które znają sie na kompach troche bardziej i czasami kombinują. Są tez tacy co korzystają z internetu w pracy, gdzie firmowe komputery zazwyczaj są w różny sposób zabezpieczane - akurat ciastek to raczej mało kiedy tyczy ale kto tam wie...

Zrobię na zasadzie metody, którą podlinkował @@cykcykacz

Zrobie ciastko przy logowaniu i odrazu sprawdzę czy istnieje, jeśli nie to przekierowanie do strony z komunikatem, że przeglądarka blokuje ciastka.

Raczej nie wyczerpałem jeszcze moich pytań odnośnie tego co chce ogólnie zrobić ze swoją stroną, tak więc pewnie poruszę jeszcze pare wątków. Tymczasem ten można zamknąć. Dzięki za pomoc : )
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2025 Invision Power Services, Inc.