Mam problrm z ktorym walcze juz jakis czas,
nie moge zwiekszyc (skutecznie) czasu zycia sesji z poziomu skryptu.
robie to w taki sposob jak pisza w manualu
http://php.mainseek.com/manual/pl/function.session-cache-expire.php
i nic nadal taki sam rezultat sesja ginie w ok 30 minut :(
probowalem tez ini_set() takze to samo (
czy ktos mial moze podobny problem ?
0
0
po prostu moze sie nie dac. wcale nie musisz miec nad tym wszystkim kontroli
0
no wlasnie ze musze, pozniewaz , pisze skrypt ktory tego wymaga :(
0
Stworz wlasna obsluge sesji. I to kompletna. To znaczy nie korzystaj z session_start(). Wygeneruj sam identyfikator:
$session_id = md5(uniqid($_SERVER['REMOTE_ADDR']))
Pozniej sam troszcz sie o zapisywanie do cookie (mozesz dane umieszczac w bazie). W taki sposob masz pelna kontrole na sesjach. I w taki sposob obchodzi sie sesjami forum phpbb i to rowniez, ktore na marginesie na 100% wzorowalo sie na phpbb. :)
0
maniek_2 napisał(a)
(...)i to rowniez, ktore na marginesie na 100% wzorowalo sie na phpbb. :)
Oj, byłbym ostrożny...
0
$session_id = md5(uniqid($_SERVER['REMOTE_ADDR']))
kiepski pomysł - bo co się stanie, jesli będzie kilku userów z tym samym IP?
0
ŁF napisał(a)
$session_id = md5(uniqid($_SERVER['REMOTE_ADDR']))
kiepski pomysł - bo co się stanie, jesli będzie kilku userów z tym samym IP?
będzie generowało różne $session_id :P
0
ŁF napisał(a)
$session_id = md5(uniqid($_SERVER['REMOTE_ADDR']))
kiepski pomysł - bo co się stanie, jesli będzie kilku userów z tym samym IP?
Poza tym nie jest to moj pomysl. Jest to pobrane z phpbb primo a secondo to forum tez tak generuje identyfikator sesji. :]
0
W konfigu spróbuj:
session.gc_maxlifetime
0
nav napisał(a)
a mozesz cos wiecej, jest gdzies jakis artukul o tym ??
jak zastapic tablice $_SESSION ?? gdzie trzymac zmienne sesyjne ??
0
session id zapisujesz w ciasteczku, ktoremu mozesz ustalic czas "zycia" na ile chcesz. potem ciacho znika, a razem z nim sesja. jak ustalic czas zycia ciacha masz w tamtym linku
0
fleming86 napisał(a)
ŁF napisał(a)
$session_id = md5(uniqid($_SERVER['REMOTE_ADDR']))
kiepski pomysł - bo co się stanie, jesli będzie kilku userów z tym samym IP?
będzie generowało różne $session_id :P
Co z tego? Nadal relatywnie latwe do zlamania. Wystarczy ze znasz IP goscia, ktoremu chcesz przejac sesje oraz orientacyjny czas poczatku sesji. Rozdzielczosc timera systemowego jest przeciez niewielka (w manualu php pisza, ze biora mikrosekundy, ale to jest nieprawda), wiec parenascie tysiecy prob wystarczy. Po diabla stosowac 128 bitowe id sesji?
Lepiej jest napisac:
uniqid($_SERVER['REMOTE_ADDR'], true)
Zgodnie z php.net, to dodaje "troche wiecej losowosci". Jedyny problem jest taki, ze php uzywa najgorszego z mozliwych generatorow losowych (tego oczywiscie na php.net juz nie napisali) - opracowanego w roku 1948 (!) LCG. Generatora tego nie wolno stosowac do zastosowan kryptograficznych.
Jak chcesz miec dobry mechanizm sesji, to niestety jestes zdany rowniez na zakodowanie w php jakiegos nowoczesnego generatora liczb losowych (ale nie jest to kwestia 50 linijek). Mozna przerobic jakies gotowce dla C/C++.
0
Krolik napisał(a)
Wystarczy ze znasz IP goscia, ktoremu chcesz przejac sesje
To juz pierwsza bariera.
orientacyjny czas poczatku sesji
Druga.
parenascie tysiecy prob wystarczy
W tym czasie sesja moze zdechnac.
Lepiej jest napisac:
uniqid($_SERVER['REMOTE_ADDR'], true)
Nie znajac zrodel nie znasz metody generowania ID. Trzecia bariera.
[...]opracowanego w roku 1948 (!) LCG.
Ciekawostka, fajnie ze o tym napisales :).
Jak chcesz miec dobry mechanizm sesji, to niestety jestes zdany rowniez na zakodowanie w php jakiegos nowoczesnego generatora liczb losowych
Jesli komus zalezy na takim poziomie bezpieczenstwa, to sesje nalezy od poczatku do konca przemyslec inaczej. Nie robmy sztuki dla sztuki ;).
Pozdrawiam
0
Masz rację - czasami nie warto się przejmować, zwłaszcza jak ktoś pisze coś jedynie dla siebie. Ale się jest profesjonalistą, to wypada stosować porządne zabezpieczenia, a nie "domowej roboty" i tyle. W kwestii bezpieczeństwa zawsze lepiej dmuchać na zimne. Kiedyś spotkałem nawet sidy generowane jako kolejne liczby całkowite z tym "utrudnieniem", że dla niepoznaki przejechane md5 [rofl].
Co do barier wymienionych przez Ciebie:
- IP: wystarczy zachęcić gościa by wszedł na odpowiednią stronę www :)
- czas sesji: moze byc b. dlugi - nawet kilka tygodni, jeśli serwis posiada opcję "pamiętaj mnie" czy "logowanie automatyczne"
- brak źródeł: na pewno? Skoro w sieci jest rozpowszechnionych kilka sposobów, a w dokumentacji jest zalecany ten co przedstawiłem, chyba nie problem je wszystkie przetestować? A co z projektami opensource?
- czas na atakowanej maszynie można np. odczytać, jeśli admin nie zablokował usługi daytime.
BTW: LCG jest nie tylko beznadziejne do zastosowań kryptograficznych, ale również w matematyce się słabo sprawdza. Ma bardzo kiepską funkcję autokorelacji. Losując pary 2 liczb, pewnych par nigdy tym generatorem nie wylosujesz. Jakich - wystarczy zajrzeć do źródeł i zobaczyć, jakie przyjęli stałe we wzorze generatora.
0
Ale o co Ci chodzi tak w gruncie rzeczy, zeby nie stosowac sesji na takiej zasadzie? Napisales, pochwaliles sie wiedza ale zadnej konkretnej ort!. Jezeli piszesz o takich problemach to krzycz na wszystkich, ktorzy stawiaja fora typu Coyot albo phpbb. Jakos do tej pory malo sie slyszy o atach na te fora tego typu co Ty piszesz. Nie "mowie" tutaj o tych dziurach wyrytych z phpbb.
0
Przeciez dalem odpowiedz: Napisac wlasne sesje w oparciu o generowanie sida jakims dobrym generatorem losowym (np. ISAAC). Wszystko zalezy od tego, jaki poziom bezpieczenstwa sie chce miec. Do forum wystarczy, to co napisali na php.net, ale do systemu obslugujacego bankowosc elektroniczna takie cos nie pojdzie. Chcialem tylko naswietlic problem, zeby nie bylo falszywego poczucia bezpieczenstwa. Mysle, ze na tym mozna zakonczyc watek.
0
A może jak w Coyote: ciasteczka mają większy czas ważności, a jeśli ciasteczko z sidem znajduje się na kompie klienta, to startuje sesję od nowa.
0
Na Coyote jest zupelnie inna idea. Nie ma tutaj czegos takiego jak session_start(). System sam tworzy identyfikator, sam probuje zczytac identyfikator z cookies a jezeli nie znajdzie to w url'u (jak i tu nie znajdzie to tworzy sam identyfikator). Jest to w pewnym sensie wieksza elastycznosc gdyz samemu mozna sobie zaprojektowac dlugosc trwania sesji.
0
Wszystko zalezy od tego, jaki poziom bezpieczenstwa sie chce miec. Do forum wystarczy, to co napisali na php.net, ale do systemu obslugujacego bankowosc elektroniczna takie cos nie pojdzie.
Jest to jeden z wielu powodów , dla których do poważniejszych projektów nie używa się php.
Taka mała dygresja.
0
No coś w tym jest, ale takich tekstów lepiej nie puszczaj na forum, bo jeszcze wywołasz flamewar.