CookieDomain, přegenerovávání PHPSESSID, nemožnost přenosu přihlášení na subdoménu

Ahoj,

jen tak hádám, zkusil jsi nastavit cookieSamesite: None, aby Jsi vyloučil tento problém?

https://doc.nette.org/…onfiguration#…

Také pozor na tohle – možná by Jsi měl nastavit tu doménu i v http?:

https://doc.nette.org/…onfiguration#…

Zkus tohle nějak vyzkoušet, třeba to pomůže.

Editoval m.brecher (11. 3. 2023 0:04)

Hm, tak jsem něco zjistil.

K předávání cookie s doménou na subdomény musí být doména ve tvaru jmeno_domeny.tld, takže například control.test, nikoliv třeba jenom „control“.

To je zákeřné pro lidi jako já, kteří si v hosts nastaví třeba jenom doménu „pomocne_stranky“ bez TLD. S tím si browser neporadí. Musí tam být vždycky ta TLD.

Problém nastává rovněž tehdy, máte-li delší doménu než jen jmeno_domeny.tld. Pokud specifikujete např.:

cookieDomain: ‚nejaka.subdomena.domena.tld‘

tak browser nebude předávat tuto cookie do ‚dalsi-subdomena.nejaka.subdomena.domena.tld‘. Vždycky to prostě musí být domena.tld.

Toto není problém Nette, je to spíš hlubší chování browserů jako takových, ale možná by stálo za to to aspoň zmínit v dokumentaci. Množství lidí, kteří vyvíjejí nějakou službu na pokusné doméně vyššího řádu (třeba alpha.sluzba.cz), asi bude nenulové.

Jo, a ještě jedna věc. Při experimentech se subdoménami je nezbytné hlídat, jaké cookies už máte v browseru z minulých pokusů. Lepší je vždycky to promazat.

Editoval DefenestrationPraha (11. 3. 2023 12:11)

m.brecher napsal(a):

@DefenestrationPraha

Dokumentace Nette: „Například při cookieDomain: nette.org jsou cookies dostupné i na všech subdoménách jako doc.nette.org. Téhož lze dosáhnout také pomocí speciální hodnoty domain, tedy cookieDomain: domain“

To co píšeš, že tam MUSÍ vždy být top level domain tak to není v rozporu s tím, co je v dokumentaci, naopak v plném souladu, jenom jsi možná špatně pochopil ty příklady:

cookieDomain: nette.org – tohle je doména včetně TLD!

cookieDomain: domain – tady autor dokumentace neměl na mysli doménu bez TLD, ale „speciální hodnotu domain“, tedy něco jako klíčové slovo

Takže bych řekl, že dokumentace je v pořádku

Četl jsem tutéž dokumentaci, ale z příkladu (jedna konkrétní doména včetně TLD) ještě automaticky neplyne, že to tak musí být pokaždé.

Dokumentace je v pořádku, jenom bych tam explicitně zmínil, že ta TLD tam být musí. Mezi příkladem a pravidlem je rozdíl.

@DefenestrationPraha

Dokumentace je v pořádku, jenom bych tam explicitně zmínil, že ta TLD tam být musí. Mezi příkladem a pravidlem je rozdíl.

V zásadě souhlasím, ale příklady typu domain.com, example.com jsou všude možně na internetu a lidi tomu rozumějí. Matoucí je to klíčové slovo domain, protože to vypadá, že to je právě ten příklad nějaké Tvojí domény bez tld. Dát tam do závorky přesnější definice by neuškodilo.

@DavidGrudl

Jak se dělá PR kdyžtak víte, že.

Ano, mám už do dokumentace tipů na vylepšení více a mám je zapsané, jen se k tomu musím dokopat abych to zformuloval do použitelného PR. Postupně je všechny pošlu. Sorry, už jsem to sliboval loni.

@DavidGrudl Ono to nějakým způsobem funguje, když použiješ nezkrácený tvar url s tečkou na konci, ale je to z mnoha důvodů nedoporučované http://ai.

https://en.wikipedia.org/…level_domain#…

Editoval Marek Bartoš (11. 3. 2023 22:40)

@DefenestrationPraha a čekal bys, že bude fungovat i https://web-project nebo https://web? Asi ne. Stejně tak není možné ukrajovat z konce názvu domény.

Jak jsem říkal, možnost existuje.

Ale upřímně, vůbec nerozumím slovům tvého kmene. Problém se týká vývoje na localhostu?

m.brecher napsal(a):

@DefenestrationPraha

velká část vývoje se odehrává lokálně, na místně běžícím Apachi

Vývoj Nette projektů na Windows sdíleně ve složkách na jednom http://localhost Apache serveru je problematika která by vydala na samostatné téma v dokumentaci. Mám už leccos doma zapsáno, co nováček musí vyřešit, aby mohl vůbec na Windows nějaký vývoj a následný deploy na webhosting zvládnout.

Mám za poslední dva roky dlouhý seznam toho, co jsem musel vyřešit a nováčkům by pomohl zhuštěný návod jak si vývojové prostředí na Windows vyladit, aby si ušetřili měsíce úmorného tápání a zkoušení.

Myslím, že ideální je problematiku toho, co je na Windows localhostu jinak, soustředit do jednoho článku v dokumentaci, než to sypat do celé dokumentace (jako třeba nastavení cookies na localhostu přidat v dokumentaci do sekce o cookies). Takže bych takový článek zkusil napsat a předložit k recenzi komunitě a pak by se mohl přes PR a vložit do dokumentace.

Jeden příklad:

– cookies na localhostu se defaultně sdílejí na celé doméně localhost, takže přihlášený uživatel v jednom projektu se objeví ve všech projektech. Řeším to tímto nastavením v konfiguraci:

local.neon:

parameters:
	cookiePath: 	@App\Utils\Config::getCookiePath()

session:
	cookiePath: %cookiePath%

http:
	cookiePath: %cookiePath%

kde soubor local.neon používám jinak než je zvykem v komunitě a sice jen na localhostu:

Bootstrap.php

		$configurator->addConfig($appDir . '/config/common.neon');
        if($_SERVER['HTTP_HOST'] === 'localhost'){
            $configurator->addConfig($appDir . '/config/local.neon');
            ini_set('open_basedir', implode(';', [$appDir, ini_get('upload_tmp_dir')]));  // ochrana dat počítače !!!
        }
		$configurator->addConfig($appDir . '/config/services.neon');

v Bootstrap.php si také „amatérsky“ chráním data počítače, protože nešikovný php script by je mohl smazat a hrabat se v uživatelských účtech Windows se mě nechce.

cookiePath mě vrací šikovná služba Config, kam si každý může dát co z konfigurace bude potřebovat – doporučuje to takto @DavidGrudl a je to ideální řešení.

class Config
{
    public readonly string $appDir;

    public readonly string $wwwDir;

    public readonly bool $debugMode;

    public readonly string $adminerDir;

    public readonly bool $productionServer;

    public function __construct(private Request $httpRequest)
    {}

    public function setParameters(string $appDir, string $wwwDir, bool $debugMode, string $productionHost, string $adminerDir)
    {
        $this->appDir = $appDir;
        $this->wwwDir = $wwwDir;
        $this->debugMode = $debugMode;
        $this->adminerDir = $adminerDir;
        $this->productionServer = $_SERVER['HTTP_HOST'] === $productionHost;
    }

    public function getBasePath(): string
    {
        $basePath = $this->httpRequest->getUrl()->getBasePath();
        return str_ends_with($basePath, '/') ? substr($basePath, 0, strlen($basePath) - 1) : ''; /* fix Nette bug */
    }

    public function getCookiePath()
    {
        return $this->getBasePath().'/';
    }
}

Je to jenom ukázka, že nějak si vychytat vývoj na localhost ve Windows není nijak snadné. Je toho ale daleko víc, poslední problém, který jsem řešil je, že Adminer Editor Jakuba Vrány pod PHP 8.1 a PHP 8.2 na Windows nefunguje díky drobné chybě v PHP správně a je nutné ho opravit. Opravený Editor mám k dispozici a dám ho veřejně k dispozici.

Tak tohle by bylo dobré udělat a tak něco připravím.

Podrobný návod pro práci na localhostu by byl skvělý.

Když tak tam mohu doplnit kapitolu o HTTPS.

Tak tu dokumentaci uprav, když to někomu pomůže.

m.brecher napsal(a):

@DefenestrationPraha

Přesně tak, a myslím si, že takových programátorů bude aspoň 10–20 procent. Na Windowsech je hodně populární XAMPP.

XAMPP neznám, instaluji si jednotlivé části samostatně, Apache, MySQL, PHP, různých chytáků při instalaci je docela dost. Při ruční instalaci Apache, MySQL, PHP na Windows člověk trochu pronikne do těch technologií.

Já bych napsal článek o ruční instalaci Apache, MySQL, PHP a jak si zorganizovat projekty ve složkách + související konfigurace v Nette + jak uploadovat na produkci Po nějaké recenzi a doplnění by se mohl publikovat.

Nevím, za co tě downvotují, toto by byl užitečný článek. Já jsem si na samostatnou instalaci všech těchto kusů SW na Windows posledních 10 let netroufl. Buď jsem používal WAMP, nebo XAMPP. Z těchto dvou musím říci, že je XAMPP hodně pohodlnější a příjemnější na užití než WAMP, ale musíš být opatrnější – například už jsem viděl databázi rozhozenou z toho, že se správně nevypnula, což se mi s WAMPem nikdy nestalo.

Napíšeš-li takový článek, zkusím jej doplnit. Nemám s tím zatím moc zkušeností, protože (smích) u nás stále používáme Subversion a zatím jsem neměl důvod se učit Git.

@MajklNajt

asi za to, že je to off-topic, a v podstate úplne mimo Nette?

Ano, souhlasím, tematicky by takový článek vybočil z topic Nette Frameworku – cca dvě třetiny by se věnovaly technologiím okolo a jednom jedna třetina Nette. Proto si také myslím, že by se to nemělo dávat přímo do dokumentace Nette, ale někam jinam a v dokumentaci by se na vhodných místech mohlo na ty články odkazovat.

Ty články i když by byly o Nette jen částečně by právě měly napumpovat do nováčků praktické znalosti z těch technologií a postupů, které MUSÍ zvládnout, aby v Nette mohli vůbec začít. Je přeci lepší investovat čas do studia komponent Nette či DI než hodiny řešit proč nefunguje skript pro otevření šablony latte v IDE z Tracy, nebo proč při přidání knihovny intl v PHP padá server Apache.

Samozřejmě je nevhodné, aby z dokumentace Nette šly odkazy na jasná off-topic témata. Manuál na instalaci a konfiguraci technologií pro domácí vývoj Nette aplikací na Windows ale uvítá každý začínající webový vývojář.

Editoval m.brecher (17. 3. 2023 0:18)

Ale vysvětlete mi jedno, proč teda ani po víc než týdnu, když vidíte v dokumentaci nějakou nejasnost (já přiznávám stále nechápu jakou), proč to v té dokumentaci neopravíte? Přes x mých výzev. Mě to připadá až neuvěřitelné, jak když někdo řeší, ať už tady na fóru nebo na Slacku, že mu něco chybělo v dokumentaci, tak se zoufale brání tomu ji doplnit. Jednou kliknout na edit. Občas dokonce někdo něco přislíbí, ALE NIKDY, NIKDY!!! z toho pak nic není. I přes opakované urgence. Připadám si jako kokot v říši slibů.

Já pak opravdu žiju v pocitu, že uživatelé jsou jen nesmírně líná banda naprostých nevděčníků, a o to hůř v sobě hledám nějakou motivaci něco vylepšovat.

Na to stačí jen účet na Githubu a dá se to editovat přímo tam:

Nebo prostě napsat: hele, Davide, nemám Github, tak změň na té a té stránce tu a tu větu za tuhle jinou.

@DavidGrudl

Tak jsem poslal do dokumentace Tracy 16 x pullrequest pro každou jazykovou verzi jeden. Bylo by asi lepší to nějak sloučit do jednoho PR, ale nepřišel jsem na to jak.

Já pak opravdu žiju v pocitu, že uživatelé jsou jen nesmírně líná banda naprostých nevděčníků

Davide, když pak na první snahu o příspěvek od nezkušeného uživatele odpovíš tímhle, tak se moc nemůžeš divit, taky by se dalo mluvit o nevděku.

Já třeba přispívám rád (do nette), ale mám problém s tvými dlouhými odezvami a nereakcemi na konceputální věci a to mě zase demotivuje něco dělat. Takže ono to nikdy není jednostranné.

Editoval dakur (5. 4. 2023 13:27)

@dakur

spíš bych viděl chybu na svojí straně, sliboval jsem poslat PR do dokumentace už loni v prosinci a dostal se k tomu až teď. Přitom to složité není, jak psal David. Na fóru jsem kdysi četl, že se mají doplňky do dokumentace psát česky i anglicky, ale možná jsem to jenom špatně pochopil. Včerejší PR beru jako testovací a jestli jsem to správně vyhodnotil, tak PR do dokumentace se aktuálně podává v jedné jazykové verzi.