Uchování informace o jazykové verzi a přihlášenosti
Školení, která pořádám 
U vícejazyčné prezentace je nutné nějak uchovávat informaci o používané jazykové verzi. Asi nejjednodušší je uchovávat ji v session proměnné, uložit se dá také do cookie nebo se dá předávat jako součást URL. První dva způsoby jsou o něco jednodušší, bohužel mají velkou nevýhodu – protože jsou různé jazykové verze na stejných URL, jsou v podstatě neviditelné pro vyhledávače a znemožňují cachování stránek. Proto je lepší informaci o jazykové verzi vždy předávat v URL, ať už v parametru (http://www.example.com/test.php?lang=cs) nebo jako virtuální adresář (http://www.example.com/cs/test.php). První způsob je pracnější při vytváření odkazů a adresy nevypadají tak hezky, u druhého způsobu je k nezaplacení nějaká podpora webového serveru (nejlépe mod_rewrite), odkazy a kód jsou pak o poznání hezčí.
Pokud se k webové prezentaci uživatel může přihlásit, je nutné tuto informaci také nějak uchovávat. Zde je naopak chybou uchovávat ji v URL, protože jak pro vyhledávače, tak pro cache se jedná o tutéž stránku. Za normálních okolností je nejvýhodnější tuto informaci uchovávat v session proměnné. Session ID se obvykle uchovává v cookie, za určitých okolností se ale může předávat i jako parametr URL, takže pro vyhledávače a cache se opět bude jednat o různé stránky. Z toho důvodu je vhodné neměnit hodnotu konfigurační direktivy session.name (např. funkcí session_name) a nechat ji nastavenou na Většina vyhledávačů se naštěstí snad již naučila ignorovat Session ID používané PHP, takže máme o starost méně.PHPSESSID, protože chytré vyhledávače (např. Google) hodnotu tohoto parametru ignorují.
Diskuse
Jan Bien:
Když už mluvíme o přihlašování, bylo by myslím vhodné zmínit i třetí, lépe řečeno vlastně první (to protože je nejsnazší), možnost, tedy HTTP autentifikaci. Viz: http://cz.php.net/features.http-authCo se týká vhodnosti přihlašování, tak v jednoduchých aplikacích je nejvhodnější výše zmíněná HTTP autentifikace pro svou jednoduchost, větší aplikace si pak říkají o používání session proměnných, resp. cookies. Předávat "sešnu" parametrem PHPSESSID je nedoporučovaný postup.
Jakub Vrána 
:
U způsobech autentizace mám napsaný článek, řešení přes HTTP není vždy ten nejlepší způsob - např. se špatně zařizuje odhlašování.
Jakub Vrána : Llaik:
Ale zase pokud pouzijes defaultni session handler, tak to neni nic jineho nez soubory na disku. Co kdyz ti pak pobezi aplikace na vice strojich?
Takze pak ti zbude jen prepsat handler ze souboru na disku na databazi a uz to sebou nese jina uskali (pokazde connect na db server apod..)
K jazykovym verzim - nejjednodussi mi prijde implementace nezmineneho domenoveho aliasu :)
spaze:
Aplikace na vice strojich, tzn. co? Jakoze jeden pozadavek v aktualnim "sezeni" pujde na stroj A a hned dalsi pujde na stroj B? (Nejdriv jsem chtel napsat, ze je to nemozny, pak jsem si ale vzpomnel na DNS round robin a uz sem zticha;) moznosti se souborama by bylo treba nejakej networked filesystem, pokud by tam nebyl problem s filelockingem, jakoze asi jo.. (hmm, mam zajimavy myslenkovy pochody, ktery nikam nevedou :)
spaze: pepper:
Jen by me zajimalo jak se ten vyhledavac bude prihlasovat kdyz je na nej bran ohled v casti jen pro prihlasene.Opravdu by me zajimalo jak se toto resi.
Jakub Vrána :
Přihlášení může být zcela automatické, uživatel nemusí nic vyplňovat, pouze se mu nastaví Session ID a je to. Navíc uživatel může vzít URL, které vidí v adresním řádku prohlížeče, vložit ho jako odkaz na svou stránku a vyhledávač se přes něj na stránku dostane.
Jakub Vrána : pepper:
PHPSESSID se ignoruje prave proto aby nedoslo k oznaceni stejne stranky s ruznym PHPSESSID za ruzne stranky se stejnym obsahem.Parametry v URL jsou brany jako soucast URL u vetsiny vyhledavacu a venuji jim pozornost a rozpoznaji co jsou stranky ruzne a co stejne.
To ze jim treba prirazuji mensi vahu je vec jina. Nebo ze se treba omezi na prvni tri parametry.
Vase reseni urcite zacatecnikovi pomohou se zorientovat v problematice uchovavani informaci pri prochazeni ruznymi strankami, nicmene je tam pomerne dost nepravd a rekl bych vymyslenych argumentu proc to a ne ono. Vetsinou otazka stoji jinak a Vami popisovana reseni se voli z uplne jinych duvodu.
Jakub Vrána :
Mohl byste být konkrétnější? Rád se něco přiučím, ale když napíšete, že jsou v článku nepravdy a vymyšlené argumenty, musíte je jeden po druhém vyjmenovat.
Jakub Vrána : pepper:
Pokud se k webové prezentaci uživatel může přihlásit, je nutné tuto informaci také nějak uchovávat. Zde je naopak chybou uchovávat ji v URL, protože jak pro vyhledávače, tak pro cache se jedná o tutéž stránku.-- vyhledavac tu stranku nikdy neuvidi, cache ji IMHO bude cachovat jako kazdou jinou stranku a nabidne ji kazdemu ktery si vyzada tu samou se vsemi parametry stejnymi.
Session ID se obvykle uchovává v cookie, za určitých okolností se ale může předávat i jako parametr URL, takže pro vyhledávače a cache se opět bude jednat o různé stránky.
--pominu li ze uz se treba nejedna o stranku na kterou se vyhledavac vubec nikdy nepodiva, je prave to session ID docela dobry rozlisovaci znak uzivatelu. Ne pro autentifikaci jen tak jak to je ale prave proto aby dva prihlaseni uzivatele vyuzivajici stejnou cache videli kazdy tu svoji stranku.
Z toho důvodu je vhodné neměnit hodnotu konfigurační direktivy session.name (např. funkcí session_name) a nechat ji nastavenou na PHPSESSID, protože chytré vyhledávače (např. Google) hodnotu tohoto parametru ignorují.
--Ano, mate pravdu Google ignoruje parametr PHPSESSID z duvody uvedenych vyse ale tech parametru je mnohem vic, protoze internet neni postaven na PHP a tim padem si lze s klidem prejmenovat tento parametr na nektery jiny z mnoha ktere vyhledavace(Google opravdu neni jediny a mnohdy ani nejdulezitejsi) ignoruji.
Ne vzdy je ale ignorovani tohoto parametru nasim zamerem jak jsem se snazil napsat vyse.
Jakub Vrána :
Vyhledávač stránku vidět může, možné scénáře jsem popsal výše. Stejná stránka pro různé přihlášené uživatele může vypadat stejně, proto je škoda použitím různých URL cachím bránit v práci. Pokud mají stránky pro různé uživatele vypadat jinak, tak existují mechanismy, jak to zařídit, ale je zbytečné si použitím různých URL před využitím cachí zavírat dveře.
Tuším, že Google a jiné vyhledávače budou ignorovat i další parametry (např. defaultní pro ASP nebo JSP), ale těžko budou ignorovat např. mySessId. Předefinovávat parametr, o kterém jistě vím, že ho Google ignoruje, na jiný, který Google taky ignoruje, nedává smysl - hodí se to "jen pro ten pocit".
Jakub Vrána : spaze:
"ale těžko budou ignorovat např. mySessId", nejsem si jist, ale je mozny, ze SE muzou ignorovat parametry, jejichz hodnota je [a-z0-9]{32}. Nekde nekdo (Yuhu, Marek Prokop, ..) psal o tom, jak to je, resp. jak by to mohlo byt.
spaze: Miloš Brecher:
Já přepínání jazykových verzí webu řeším pomocí systému url. Všechny stránky české verze začínají /, cizojazyčné verze začínají /en/, /de/ apod... Přejít na url jiné jazykové verze jde pouze v menu přepnutí jazyka.Diskuse je zrušena z důvodu spamu.
© 2005-2024 