[michael94]

@jacekprim: kiedy nakłamałeś w CV panie programista wypoku ( ͡º ͜ʖ͡º)

[jacekprim]

@michael94: Wykop miał ten sam problem, ale prawdopodobnie nie używa wbudowanych sesji, tylko ma własny mechanizm, skoro może wygenerować ich listę.

Poza powyższym niepodobającym mi się rozwiązaniem widzę jeszcze inne gorsze, ale lżejsze - trzymanie haseł czystym tekstem w sesjach i ich weryfikacja przy każdym wyświetlaniu strony.

[wiesiu2]

@jacekprim: Umieść sesje w bazie i po problemie, będziesz miał pełną kontrolę.

[Gilbertus]

@jacekprim: Albo przy logowaniu zapisuj która sesja jest kogo.

[Vender]

unserialize()

@jacekprim: Nie można unserializować niezaufanych danych, a takimi ciasteczka są zawsze, nawet php.net o tym wspomina

Warning

Do not pass untrusted user input to unserialize() regardless of the options value of allowedclasses. Unserialization can result in code being loaded and executed due to object instantiation and autoloading, and a malicious user may be able to exploit this. Use a safe, standard data interchange format such as JSON (via

[Vein]

@wiesiu2: @Vender: @jacekprim: sesje trzymamy np w redis, w razie zmiany hasła kasujemy wpisy z redis tego usera... W zalezności jaką chcesz mieć politykę, ustawiasz taki TTL wpisów w redisie, np ustawiasz TTL na 7 dni i niezależnie czy się wyloguje ręcznie to go wywali.

[maniac777]

@jacekprim: w sesji trzymasz date jej utworzenia, a w bazie date ostatniej zmiany hasla. Jezeli sesja jest starsza niz haslo to ja uniewazniasz w momencie proby uzycia.

[H4v3n]

@jacekprim: sesje w bazie, np redis.

[Jurigag]

@jacekprim: przecież poza wbudowanym mechanizmem sesji w phpie powinieneś też przechowywać je w bazie a by mieć jak powiązać konkretnego użytkownika z id sesji.... i wiedzieć kiedy z niej skorzystał itd, przynajmniej wg mnie, najgorsze właśnie jest IMHO przechowywanie tylko id użytkownika w sesji i siema i zero posiadania takowej informacji w bazie