https mi automaticky presmeruje na http

Dakujem, za nakopnutie, nemyslel som že routovanie budem riešiť ako prvé :), funguje to čo potrebujem a viem ako pokračovať.

ešte raz dakujem

Žádné dobré řešení mě nenapadá. Přidej si zatím to presenteru public $autoCanonicalize = FALSE a zduplikuj tu routu (jedno se secure jednou bez).

Pokud je obsah k dispozici na více adresách, tak vždycky přesměruje na jednu hlavní, čímž předchází duplicitám obsahu z hlediska SEO.

Jan Tvrdík napsal(a):

Přidej si zatím to presenteru public $autoCanonicalize = FALSE a zduplikuj tu routu (jedno se secure jednou bez).

Tak $autoCanonicalize = FALSE v BasePresenter-i som uz nastavene mal, duplikacia rout nepomaha (vzdy sa Nette riadi tou, ktora je uvedena ako prva – ked dam prvu bez SECURED, vsetky linky sa smeruju na HTTP, ked je prava nastavena s priznakom SECURED, tak zase vsetko je smerovane na https. :(

Any other idea? Pripadne, ako napisat routu, ktora by sa ‚chytila‘ len na http/https? (ked dopredu nepoznam host-a ani basePath – takze URL je v obecnom tvare napr.: „http://subdomain.domain.com/base/url/module/presenter/action?id=10“ )

Odkial (= z akeho prostredia a kto ich poskytuje) sa daju ziskat premenne $basePath a $baseUri, ktore su dostupne v sablonach?

David Grudl napsal(a):

Málo se to ví, ale vyhledávače vnímají

http://example.com/stranka
https://example.com/stranka

jako dvě naprosto jiné adresy.

A tiez mi stale vrta v hlave otazka, ci je to naozaj ziadane chovanie, alebo ci je to chybicka. Chapem argumentu, ze http/https su brane ako 2 rozne adresy a teda auto-kanonizacia URL ich prevadza na jednotny standartny tvar (http/https podla nastavenia priznaku SECURED=false/true danej routy). Nicmenej, preco sa Nette sprava uplne rovnako aj pri vypnutej kanonizacii? Logicky spravne by mi prislo spravanie, pri ktorom:

• ked dana routa neberie do uvahy schemu v ‚match‘-fazi (= ‚chyta‘ sa na http aj https), tak by ani pri generovani NEMALA tu schemu upravovat/menit.
• ked dana routa berie schemu v ‚match‘-fazi do uvahy (vyzaduje ju k tomu, aby rozhodla ci ona je spravnou routou daneho poziadavku alebo nie), tak tuto schemu bude aj ‚vnucovat‘ v generovanych linkoch.

Pripada mi, ze priznak SECURED vykazuje len polovicu takehoto spravania – ovplyvnuje len fazu generovania, ale uz nevypoveda nic o faze ‚match‘-ovania danej routy. Takze hoci je zadana adresa nad http, tak sa uspesne match-ne aj SECURED routa. Nasledne vygenerovanie linku nad https je uz spravne.

Co ma v suvislosti s Davidovym vyjadrenim, ze adresy http://example.com/stranka a https://example.com/stranka su povazovane za dvě naprosto jiné adresy, privadza k nazoru, ze to je asi vazne Nette routing BUG. Pretoze ak tieto 2 adresy predstavuju rozne ‚zdroje‘, tak ich mozem obsluhovat roznymi modulmi/prezentermi/akciami, takze chcem pouzit 2 routy, ktore sa lisia prave schemou. Takze routa, ktora je „NOT_SECURED“ by sa nemala matchnut na adresy nad HTTPS a naopak. Dokazem si zivo predstavit prakticke priklady pouzitia takehoto chovania…

Co si o tom vsetkom myslite, a hlavne co si mysli David? :) Je moja uvaha v niektorom bode chybna/mylna? Unika mi nieco?

Vopred diky za pomoc.

a co to zkusit vyřešit pomoci htaccess, to by nešlo?

RewriteEngine On
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://www.example.com/$1 [R,L]

Neslo – to neriesi problem generovania linkov. Navyse kazdy dotaz od klienta smerovany na HTTP by sposoboval 2× dotaz na server (1 povodny dotaz + presmerovany serverom na HTTPS). Navyse by to zase vsetko presmerovavalo na HTTPS a to nechcem.

Chcem len zachovavat schemu, ktoru si uzivatel vybral pre pristup na stranky.

worsik

Díky moc. Takové jednoduché řešení, ale dumal jsem nad ním a hledal jsem ho asi hodinu.

Tiež som nad tym bádal prečo mi aplikácia nefungovala na produkčnom https a na vývojovom http bolo všetko ok. Naviac som mal v konfigurácii servera nastavené presmerovanie z http na https, takže sa to presmerúvalo stále dokola.

Nešlo by upraviť Route::constructUrl tak, aby preberal schému (http/https) z druhého parametra ($refUri) v prípade, keď nie je nastavený Route::SECURED flag? Súčasný spôsob mi pripadá zbytočne komplikovaný.

Teda zo zúčasného:

<?php
	// ...
	// riadok 365 v Route.php
	$uri = ($this->flags & self::SECURED ? 'https:' : 'http:') . $uri;
	// ....
?>

Napr. nejako takto:

<?php
	// ...
	// riadok 365 v Route.php
	$uri = ($this->flags & self::SECURED || $refUri->scheme == 'https'? 'https:' : 'http:') . $uri;
	// ....
?>

Verzia Nette: 2.0-dev, 7616569 released on 2011–03–10

Route::$defaultFlags je dobre (diky za tip), ale nie jednoduchšie, ako „nemusieť nastavovať vôbec nič“.
Možno lepšie chovanie by bolo:

1. má routa SECURED flag? ⇒ bude https
2. má routa (napr.) NOSECURED flag? ⇒ bude http
3. nemá ani jeden z nich ⇒ protokol bude závisieť od aktuálneho protokolu ($refUri->scheme)

Takto by išlo routam vynútiť http, https a fungoval by aj default – podľa protokolu aktuálnej požiadavky. Je to na zamyslenie.

Na problém jsem narazil i v Nette 2.0 a protože nemám možnost doplnit potřebné znalosti do dokumentace, kde zoufale chybí, píšu alespoň sem jak jsem problém vyřešil. Jak známo v Nette 2.0 neexistuje ani objekt Application tudíž nemůže mít ani metodu getHttpRequest() a problém se tak řeší trochu oklikou přes getService(‚httpRequest‘). Snad tím ušetřím tápání v naprosto nedostačující dokumentaci těm méně znalým:

<?php
Route::$defaultFlags |= ($container->getService('httpRequest')->isSecured() ? Route::SECURED : 0);
?>

PS: byl by opravdu takový problém lidem, kteří mají účet ve fóru, (případně nějak dále vybraným) dát možnost opravovat a doplňovat dokumentaci? Ušetřila by se tím spousta času a nervů těch, kdo v ní marně něco hledají (než pochopí, že nejvíc se toho dozví stejně na fórech).