Podstrony
- telcocafe
- Logowanie do MySQL-a Problem z zalogowanie sięDOklienta MySQL
- PhonGet "Nowy" mechanizm logowania..
- [PHP][MySQL]Jakie zapytanie do MySQL dla formularza logowania?
- [PHP] Skrypt logowania wielu użytkowników i status on-line poszukuję takowego...
- [php] Logowanie na sesjach Na thc.net.pl dziala a na 60free juz nie
- [php][mysql] skrypt logowania - problem z sesjami "Nie masz autoryzacji" ;p
- Przy logowaniu pokazuje sie poprzedni login i hasl Jak tego uniknac ?
- [php] panel admina, usuwanie newsów, przekierowanie do logowania :/
- [php] logowanie troche inaczej.. 5 plikow pytanie z prostego skryptu..
- vBulletin-zablokowana możliwość pisania postó w, rejestracji i logowania
- zanotowane.pl
- doc.pisz.pl
- pdf.pisz.pl
- jungheinrich.pev.pl
telcocafe
Temat otwarty ze względu na to, byście napisali, dlaczego akurat ten sposób jest lepszy...Hmm... ja zrobiłbym to w cookiesach. Można by wtedy było dać opcję automatycznego logowania przy każdej wizycie i zdaje mi się że będzie to też łatwiejsze rozwiązanie do wykonania (przynajmniej dla mnie) ;)
Hmm... ja zrobiłbym to w cookiesach. Można by wtedy było dać opcję automatycznego logowania przy każdej wizycie i zdaje mi się że będzie to też łatwiejsze rozwiązanie do wykonania (przynajmniej dla mnie) ;)
Co wtedy, jeśli serwer nie obsługuje sesji?
Pozostaje zrobić użytkownikowi do wyboru - z resztą to nie tak dużo...
wg. mnie to w cookies gdyz jest to wygodniejsze i latwiejsze rozwiazanie
wg mnie oba rozwiązania. normalnie używasz sesji. jeżeli user zaznaczy coś w stylu "Zapamiętaj mnie" używasz cookies.
Użytkownik ARJ edytował ten post 29 kwiecień 2005, 18:42
Powracam do tematu. Jednak wybiorę samo cookies (nawet gdybym użył sesji, także musiałbym w cookies przechowywać wpisane dane - login i hasło MD5 w przypadku zapamiętywania użytkownika). Przesłanie loginu i zaszyfrowanego MD5 hasła z cookies nie powinno trwać długo.
PHP-Fusion także korzysta z cookies. To jednak łatwiejsze rozwiązanie.
a jeżeli user ma zablokowane przyjmowanie cookies?
Chyba, że zrobić własną obsługę sesji. Jest o tym artykuł na webcity.pl
Mozna wtedy się uniezależnic od przesłodzonych ciasteczek i standardowych sesji.
Zalety: prawie same ;)
a jeżeli user ma zablokowane przyjmowanie cookies?
No tak, ale prawdopodobieństwo, że ktoś wpisze ID, które znajduje się akurat w bazie, w niewygaśniętych sesjach jest bardzo znikome. To też oczywiście zależy od tego co przyjmiemy za ID sesji, bo równie dobrze może to być jakiś ciąg kilkudziesięciu znaków, jak i zwykła liczba.
co do cookies to uwzględnij że ktoś a) przechwyci cookie użytkownika B) korzystając z błędów w CMSie przechwyci hash md5 hasła użytkownia => Podrobienie cookie, np. admina. Z dodatkowych zabezpieczeń:
- zapisz w bazie przy logowaniu IP z jakiego nastąpiło i uznawaj cookie tylko dla tego IP :)
- zakryptuj całe cookie jakąś klasą kryptującą (co potrafi odkodować a kodowanie prowadzone jest poprzez klucz - łańcuch podany gdzieś w configu strony)
ferrari -> jeżeli aż tak Cię martwi niewylogowanie to zrób takżeby musiało się wylogować. po 10 minutach bezczynności wywal go z sesji. zaszyfruj to wszystko przy użyciu SSL 3.0 i nie ma problema. Do tego dodaj kod w stronie że przy zamykaniu okna bez ywlogowania autopmatycznie się wyloguje. Jeszcze jakies zastrzeżenia?
Jeśli użytkownik jest zapamiętywany, i tak dane muszą być w cookies (hasło będzie zakodowane MD5 albo hash (lub algorytm base64), loginu raczej nie trzeba kodować).
Logowanie bez pamiętania danych mogę oprzeć na sesjach. Jest tu jeden problem - session_register()... Da się to jakoś zrobić, by pasowało dla konfiguracji z register globals on i register globals off?
Indetyfikator dopisywany byłby do adresu.
Co myślicie o logowaniu:
<?php  if (!isset($_SERVER['PHP_AUTH_USER'])) {   header('WWW-Authenticate: Basic realm="My Realm"');   header('HTTP/1.0 401 Unauthorized');   echo 'Tekst do wysłania, jeśli użytkownik wciśnie przycisk Anuluj';   exit;  } else {   echo "<p>Hej {$_SERVER['PHP_AUTH_USER']}.</p>";   echo "<p>Twoje hasło to {$_SERVER['PHP_AUTH_PW']}.</p>";  } ?> Powyższy przykład pochodzi z podręcznika PHP.
Czy wykorzystując logowanie przeglądarki nie byłoby lepsze? Większość ten sposób obsługuje (jak tam z Lynx?). Wtedy nie byłoby skryptowego zapamiętywania hasła, przeglądarki mają taką możliwość (IE, Firefox na pewno).
Oczywiście, okno logowania pokaże się wtedy, gdy istnieje pewne cookie.
Jeśli użytkownik jest zapamiętywany, i tak dane muszą być w cookies (hasło będzie zakodowane MD5 albo hash (lub algorytm base64), loginu raczej nie trzeba kodować).
Logowanie bez pamiętania danych mogę oprzeć na sesjach. Jest tu jeden problem - session_register()... Da się to jakoś zrobić, by pasowało dla konfiguracji z register globals on i register globals off?
Indetyfikator dopisywany byłby do adresu.
Co myślicie o logowaniu:
<?php  if (!isset($_SERVER['PHP_AUTH_USER'])) {   header('WWW-Authenticate: Basic realm="My Realm"');   header('HTTP/1.0 401 Unauthorized');   echo 'Tekst do wysłania, jeśli użytkownik wciśnie przycisk Anuluj';   exit;  } else {   echo "<p>Hej {$_SERVER['PHP_AUTH_USER']}.</p>";   echo "<p>Twoje hasło to {$_SERVER['PHP_AUTH_PW']}.</p>";  } ?> Powyższy przykład pochodzi z podręcznika PHP.
Czy wykorzystując logowanie przeglądarki nie byłoby lepsze? Większość ten sposób obsługuje (jak tam z Lynx?). Wtedy nie byłoby skryptowego zapamiętywania hasła, przeglądarki mają taką możliwość (IE, Firefox na pewno).
Oczywiście, okno logowania pokaże się wtedy, gdy istnieje pewne cookie.
Więc jak jest najbezpieczniej? Zaraz... da się problem rozwiązać z SQLem.
BŁĄD/ROZWIĄZANIE 1.
Wpisane dane - komórki w SQLu (sesje własne)
Indetyfikator sesji - cookies
Typ autoryzacji: sprawdzenie, czy w ID sesji (pobranym z cookies) w SQLu wpisane dane są takie same, jak w danych o użytkowniku.
Błąd: zmiana ID sesji może spowodować dostęp do innego użytkownika.
Rozwiązanie: dodatkowy element - kod ochrony (także zapisywany w cookies) oraz szyfrowanie.
Czy to dobre rozwiązanie? Każda sesja ma inny kod ochrony (generowany m. in. funkcją RAND).
Użytkownik Ferrari edytował ten post 22 maj 2005, 16:57
Nie wystarczy hash np. hasła i czasu logowania jako identyfikator sesji? Kto Ci trafi na identyczny, jak jakiś innego usera, i to akurat wtedy gdy tamten użytkownik jest zalogowany (jego sesja istnieje w bazie)?. Bo sesje powinny być niszczone np. po upływie kilkunastu, kilkudziesięciu minut nieaktywności użytkownika.
Niszczone... Oczywiście, te, w których użytkownik przy logowaniu nie włączył pamiętania hasła?
Tak. Jeśli natomiast user życzyłby sobie o zapamiętanie hasła (a właściwie sesji, tyle, że on by nie wiedział, że to sesja się zapamiętuje, a nie hasło), to zrobiłbym tak, że podczas odtwarzania zapamiętanej sesji generowany byłby jej nowy ID (np. z uwzględnieniem czasu, bo czas ciągle się zmienia).
To tylko moje zdanie :)
logowanie to dobra sprawa
Coś mi się nie udaje. Choć ciastko się zapisuje, w skrypcie nie jest widoczne. Czy w tym przypadku potrzebny jest zapis domeny i ścieżki do SETCOOKIE?
Inny problem - RANDOM.
Zawsze generowana jest jedna liczba. Dlaczego?
$uind=rand(10,100).date(dmHi).rand(10,100);
To samo jest zapisywane do ciastka i do bazy, a wartości inne.
Zajrzyj TUTAJ
Jednak odnosi się to tylko do PHP w wersji < 4.2.0. Może taką masz i dlatego.
Mam nawet PHP5. A co do logowania - jakieś uwagi? Potem pokombinuję jeszcze z domeną i ścieżką, ale to nic nie da, jeśli wartości SID będą różne.
Pokaż jak "produkujesz" ;) ciasteczka.
Random u mnie działa (PHP 5, nie używałem srand()).
$xuser=strtolower($snduser); $xpass=md5($sndpass); db_read('ID,login,pass','users','tmpu','oa',' WHERE login="'.$xuser.'"'); if(empty($tmpu['login']) || empty($tmpu['pass'])) { exit; } if($tmpu['login']===$xuser && $tmpu['pass']===$xpass) {  $uind=rand(10,100).date(dmHi).rand(10,100);  if(isset($sndr))  {  $utime=600;  }  else  {  $utime=2300000;  }  db_q('INSERT INTO '.$db_pre.'sessions VALUES ('.$uind.','.$tmpu['ID'].',"'.$xuser.' ","'.$xpass.'",'.$utime.')');  setcookie($cms_c.'login',$uind,time()+$utime) or exit;  unset($uind,$utime);  Header('Location: http://'.$_SERVER['HTTP_HOST'].'/'.dirname($_SERVER[ 'PHP_SELF']).'/index.php');  exit; }
To jest aktualny kod.
1. Cookies jest niewidoczne. Czy w tym przypadku potrzebna są: domena i ścieżka?
2. RAND() generuje liczbę poprawnie, lecz do bazy zamiast $uind próbuje się wcisnąć zawsze jedna i ta sama wartość. Dlaczego?
Jeden problem rozwiązałem (z bazą) - za długa wartość była.
Co więc z cookies? Są niewidoczne (dlaczego?).
Teraz cookies są widoczne (spowodowane dwoma znakami / w adresie). Zobacz do HEADER - ta część kodu przekierowuje na wykryty przez PHP adres.
Czy lepiej będzie, gdy w pliku konfiguracyjnym wstawię zmienną z domeną i ścieżką i z tych danych korzystać (w header)?
LOGOWANIE NAPRAWIONE.
Wprowadzę jednak domenę i ścieżkę do konfiguracji. PHP nie zawsze musi poprawnie wykryć wszystko i cookies może się nie odczytywać. Użytkownik przy instalacji i w konfiguracji będzie miał wgląd do tych danych.
Jeszcze jedno
Jak tu najlepiej sprawdzać czas upływu sesji?
Użytkownik Ferrari edytował ten post 23 maj 2005, 21:16
Jeśli dobrze myslę to $utime jest u ciebie czasem upływu, a właściwie czasem zdatności do użycia. No to chyba musisz jeszcze zapisać czas, w któym sesja została stwrzona, albo po prostu pod $utime zapisz time()+czas_aktywności_sesji. Potem to już tylko porównywanie tego z aktualnym czasem.
OK - nie dałoby się tego zapisać pod mniejszymi liczbami, nie kombinując z datami (np. 2005 jako skrócenie)?
Samego roku nie możesz zapisać, chyba, że czas dla sesji określałbyś w latach ;) Dlateczo zależy Ci żeby to były krótsze wpisy? Zresztą jak zapiszesz time(), czyli liczbę całkowitą to zajmie ona tylko 4 bajty (chyba), w końcu to integer.
By było krócej, czas będzie liczony od roku 2005. Zamiast INT zastosuję varchar.
Dobrze by było, gdyby użytkownik nie został wylogowywany po upływie czasu np. 5 min, gdy ma otwarte okno przeglądarki.
Da się tak zrobić, by przy zamknięciu okna przeglądarki wysłać polecenie do SQLa?