Některé uživatele aplikace nepřihlásí

Marek Znojil
Člen | 90
+
0
-

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
+
0
-

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?

Marek Znojil
Člen | 90
+
0
-

Opravdu nikoho nic nenapadá?

Pavel Kravčík
Člen | 1196
+
+2
-

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
+
0
-

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
+
0
-

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
+
0
-

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
+
+1
-

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
+
0
-

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
+
0
-

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
+
+1
-

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
+
0
-

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.