Některé uživatele aplikace nepřihlásí
- Marek Znojil
- Člen | 90
Zdravím,
v poslední době se nám sem tam ozvou zákazníci, že je stránka po přihlášení vlastně nepřihlásí. Zajímavé je, že se to dnes stalo i u člověka, kterému mu to do teď šlo. Netušíte, kde by mohl být problém?
Nastavení session:
session:
autoStart: smart
cookieSamesite: None
debugger: true
expiration: 14 days
name: sid
Mně osobně se chybu doteď nedařilo nějak nasimulovat.
- Marek Znojil
- Člen | 90
Ještě si vybavuji, že nám kdysi roboti procházením vyčerpávali maximální počet inodů. Při každém znovu načtení se vždy vytvořilo nové sezení. Tehdy jsem to vyřešil tak, že jsem ochranu proti CSRF zapnul pouze pro přihlášené a omezil také používání metody storeRequest() aby se to opět nezahltilo.
Dle všeho to možná souvisí? Protože to vypadá tak, že se aktuálně vytvořené sezení po znovu načtení není zapamatováno (Jen u některých uživatelů, ale proč?).
Neřešil jste náhodou někdo něco podobného?
- Pavel Kravčík
- Člen | 1196
Ideálně od těch konkrétních klientů zkus vyžádat
F12->Application->Cookies
screen. Vypadá to, že tam
pravděpodobně bude, ale z nějakého důvodu nevalidní.
Plus bych prověřil verze na základě tohohle: https://forum.nette.org/…uboru-za-den#…
- Marek Znojil
- Člen | 90
Pavel Kravčík napsal(a):
Ideálně od těch konkrétních klientů zkus vyžádat
F12->Application->Cookies
screen. Vypadá to, že tam pravděpodobně bude, ale z nějakého důvodu nevalidní.Plus bych prověřil verze na základě tohohle: https://forum.nette.org/…uboru-za-den#…
Ahoj, děkuji ti, to mě nenapadlo, zkusím.
Jinak verzi nette/http
mám 3.3.
- Marek Znojil
- Člen | 90
Tak mi tedy klient poslal toto:
Zde jsou cookies sid po vykonání akce, po které se má
vytvořit session, neexistuje-li:
A zde po znovu načtení stránky:
Nechápu ten tvar delší sid, vůbec tomu nerozumím v jakém bodě se to
může vytvářet. Ta delší, zdá se nahradí tu kratší (správnou) a proto
se neuchová původní sezení.
Delší sid je ještě k tomu platná pro doménu bez www a kratší správně pro verzi s www. Tuší někdo, proč se tak děje?
Editoval Marek Znojil (20. 11. 15:24)
- Marek Znojil
- Člen | 90
Tak to vypadá na tvar sid seznamu, ale proč ji prohlížeč ukazuje klientovi vytvořenou pod naší doménou netuším.
- Marek Bartoš
- Nette Blogger | 1275
Tak to vypadá na tvar sid seznamu, ale proč ji prohlížeč ukazuje klientovi vytvořenou pod naší doménou netuším.
Spíš si projdi nastavení session před spuštěním a po spuštění Nette
aplikace. Případně pokud tam máte nějaký skript pracující se session,
bez Nette – to bys mohl potvrdit z dat ze session uložené na serveru.
Podezříval bych session.auto_start a session.sid_length.
Jako jednoduchý workaround by mohlo pomoci změnit session.name, aby Nette
vytvořilo cookie s jiným jménem.
Delší sid je ještě k tomu platná pro doménu bez www a kratší správně pro verzi s www.
Máte redirect na www na úrovni webserveru nebo až v php?
Editoval Marek Bartoš (20. 11. 18:33)
- Marek Znojil
- Člen | 90
Spíš si projdi nastavení session před spuštěním a po spuštění Nette aplikace. Případně pokud tam máte nějaký skript pracující se session, bez Nette – to bys mohl potvrdit z dat ze session uložené na serveru. Podezříval bych session.auto_start a session.sid_length.
Nastavení se liší pouze v cookie_httponly
,
cookie_lifetime
a name
dle hodnot z Nette. Bez Nette
tam jsou klasické výchozí hodnoty. auto_start
je Off nastaven
i jako výchozí bez Nette. Všechny skripty jinak jedou pod Nette.
Máte redirect na www na úrovni webserveru nebo až v php?
Webserveru. Na aplikaci směřuje několik domén, které jsou jako alias a každá má své nastavení dle potřeby. Zde ale podpora z hostingu nevidí problém.
Jako jednoduchý workaround by mohlo pomoci změnit session.name, aby Nette vytvořilo cookie s jiným jménem.
Také mě to napadlo, nejspíš to vyzkouším, ale počkám do pozdější hodiny.
Jinak: V Chromu teď tu cookie sid seznamu vidím také, ale pro doménu
.seznam.cz
.
- Marek Bartoš
- Nette Blogger | 1275
V Chromu teď tu cookie sid seznamu vidím také, ale pro doménu .seznam.cz.
Když je domain odlišná od té aktuální, tak by je měl prohlížeč odlišit a vůbec by ti cookie pro odlišnou doménu na server neměla přijít. Problém by způsobit neměly, i když mají cookies totožné jméno s cookies z tvé domény. Takže v tom problém nebude.
Zkus vysledovat, v jaké situaci se to děje – podezříval bych backlink po přihlášení. Když voláš storeRequest(), tak se ti neukládá jen url adresa, ale celý aktuální Nette\Application\Request. Zkus místo toho redirectnout na homepage, bez obnovení původního requestu, pro otestování problému. Pokud půjde o toto, tak pak přijde na řadu analýza dat z $_SESSION, kam se request ukládá.
- Marek Bartoš
- Nette Blogger | 1275
Marek Znojil napsal(a):
Ještě si vybavuji, že nám kdysi roboti procházením vyčerpávali maximální počet inodů. Při každém znovu načtení se vždy vytvořilo nové sezení. Tehdy jsem to vyřešil tak, že jsem ochranu proti CSRF zapnul pouze pro přihlášené a omezil také používání metody storeRequest() aby se to opět nezahltilo.
Dle všeho to možná souvisí? Protože to vypadá tak, že se aktuálně vytvořené sezení po znovu načtení není zapamatováno (Jen u některých uživatelů, ale proč?).
Neřešil jste náhodou někdo něco podobného?
Jestli myslíš formulářovou komponentu CsrfProtection (metoda addProtection()), tak ta při vytvoření startuje session. Request od bota vytvářející formulář nastartuje session. Bot si session nepamatuje, takže ti session při každém takovém requestu vytvoří znova. Nová sesion = nový soubor = nový inode.
Na přihlašovací formulář to opravdu není potřeba používat – request z cizího webu nemůže za uživatele nic vykonat, není přihlášený. Maximálně by ho mohl zkusit přihlásit, ale to by v první řadě musel znát jeho login.
S tvým aktuálním problémem form protection nejspíš nesouvisí, leda že by během toho odhlášení probíhalo přesměrování na jinou doménu a zpět.
Afaik už by ochrana formulářů přes session ani neměla být potřeba (pokud podporuješ moderní prohlížeče a máš pod kontrolou všechny subdomény) – Nette si kontroluje cross-origin (a dovoluje ho povolit pro konkrétní handlery a formuláře) od verze 3 pro handlery a od verze 3.1 pro formuláře. https://blog.nette.org/…te-forms-3-1
- Marek Znojil
- Člen | 90
storeRequest()
právě vůbec nepoužívám, zpětný odkaz si
předávám persistentním parametrem a po zpracování přesměruji metodou
redirectUrl()
. Funguje to také a nemusím vůbec startovat
session, není-li uživatel přihlášen nebo jinak potřeba.
Těžko říci jestli to vůbec nějak souvisí. Asi vážně zkusím změnit ten název.