Prekladova tabulka domena → persistent lang parameter

JakubJarabica

Zdravim, mam zatial jednojazycnu appsku pricom jednoduchym pridanim za lubovolnu url ?lang=en sa nastavi persistentna premenna $lang definovana v basepresenteri a prenasa sa mi po celom webe. Mam ponastavovany translator aj vsetko okolo, ale mam problem s vyriesenim routovania. Klient ma zakupenych viac domen(napr. .sk, .cz) pricom v niektorych nazvoch sa vyskytuju pomlcky(teda treba dbat na to ze sa nemeni len koncovka). Potreboval by som vyriesit routovanie tak, aby sa mi na zaklade domeny(..pouzit prekladove slovniky?) nastavil persistentny parameter lang tak, ako chcem. Momentalne vsak nemam ani predstavu ako to rozumne docielit, vsetky priklady co prechadzam sa nesustreduju na domenu, pricom zrovna ona je to, co potrebujem teraz menit.

Druhy suvisiaci problem vidim v udrzani prihlasenia uzivatela. Kedze sa jedna o ine domeny, tak budu aj ine cookies a pri prepnuti jazyka(=presmerovani na inu domenu) sa strati prihlasenie. Tu ma napadlo spravit nejake specialne redirecty s nejakym keyom, ktory by si predavali domeny medzi sebou a pri prechode by vzniklo nove prihlasenie – to mi vsak pride ako dost hlupe riesenie.

Druhy problem by som zatial nesilil riesit, skor by ma zaujimal prvy. Dakujem za vsetky rozumne podnety :-)

Ondřej Mirtes

Napsání vlastního routeru, klidně může podědit Route a tuhle logiku si tam přidat.
Tohle nemá smysl řešit, mohla by tam vzkniknout nějaká bezpečnostní díra. Cookies nejsou omezené na jednu doménu jen tak pro nic za nic. Že se uživatel registruje a přihlásí v jiné jazykové verzi, než jakou chce používat, je hodně nepravděpodobné (pokud by to udělal 1 z 10000 zaregistrovaných, divil bych se) a fakt bych takovou situaci neřešil.

Pokud každá jazyková verze běží na jiné doméně (třeba cz/de/hu/com), tak bych vůbec začal u úvahy, jestli se uživatel např. z Maďarska dostane na českou verzi – IMHO nemá jak s tou adresou přijít do styku, z reklam a vyhledávačů ve své zemi se dozví jedině o té .hu variantě.

VasekPurchart

No tohle by se právě vyřešit mělo – stačí aby ten maďarskej uživatel měl nainstalovanej browser v angličtině a ne maďarštině a už se tam dostane jedna-dvě. Nebo vyhledávání google – občas používám jen anglický výsledky. No a nebo prostě když se uživatel bude hlásit z cizího prostředí (na dovolený).

A vzhledem k tomu, že právě nikdy neviděl jinou verzi než svojí, ale v angličtině se klidně dokáže přihlásit, tak když ho to pak přesměruje a najednou nic, tak to je dost WTF faktor.

Ondřej Mirtes

Přeci když mi jazykové verze běží na různých doménách, tak z principu je nějaká detekce jazyka a redirecting nesmysl – přišel jsem na tuhle doménu, tak v tom jazyku to chci mít.

Pokud se uživatel hlásí z cizího prostředí, tak to taky nespadá do oblasti, kterou je třeba řešit, protože v cizím prostředí přeci nemá stálé přihlášení.

Ano, může se stát, že jsem na dovolené v zahraničí, nějakým způsobem se tam dostanu na doménu s jinou jazykovou verzí, než doma používám, tam se přihlásím a teprv pak překliknu na mojí jazykovou verzi (a budu odhlášen), ale to je právě ten 1 z 10 000 případů.

Fakt bych se tím netrápil.

VasekPurchart

Tak ještě uvedu příklad, který jsem dávál Ondrovi na IM, když jsme to teď diskutovali na IM.

Server poskytuje lokalizované výsledky podle jazykové verze – pak chci přepínáním jazykových verzí ovlivnit i tyto záležitosti, takže zcela cíleně přecházím mezi verzemi, ale přihlášen určitě chci zůstat.

Btw jak jsme zjistili, tak u google i při přecházení mezi doménami přihlášení zůstává, takže nějak to půjde :)

Patrik Votoček

manik napsal(a):

No tohle by se právě vyřešit mělo – stačí aby ten maďarskej uživatel měl nainstalovanej browser v angličtině a ne maďarštině a už se tam dostane jedna-dvě. Nebo vyhledávání google – občas používám jen anglický výsledky.

Pokud vyhledávám na google anglicky asi se chci dostat na web který mluví anglicky.

No a nebo prostě když se uživatel bude hlásit z cizího prostředí (na dovolený).

Typnul bych to na méně než 1 promile uživatelů. Navíc tam asi stále přihlášení moc řešit nebude.

A vzhledem k tomu, že právě nikdy neviděl jinou verzi než svojí, ale v angličtině se klidně dokáže přihlásit, tak když ho to pak přesměruje a najednou nic, tak to je dost WTF faktor.

Nevím no ale řekl bych že 90% se nejdříve přepne do svého jazyka a pak se teprve přihlašuje…

EDIT: kua pozdě to je tak když otevřu XXtabů a pak je postupně procházím.

Editoval vrtak-cz (13. 5. 2010 1:54)

JakubJarabica

Tak predsalen sa mi to podarilo dokopat aj bez vlastneho routeru.

Do rout som pridal pred zaciatok regularu //<lang>, nastavil som som si FILTER::IN a FILTER::OUT, kde bol len jednoduchy switch, v ktorom sa menil nazov domeny a vracal sa prislusny lang parameter. Kedze mam aj persistentny parameter $lang, tak sa automaticky nastavuje a prenasa. Jedine co ma na tom stve je, ze mi nefunguje FILTER::TABLE, nakolko ma presmeruje na url http://sk/. Kazdopadne funguje to, som rad :)

Co sa tyka toho trvaleho prihlasenia, Google je ten, ktory ma utvrdil v tom, ze nejako to fungovat musi. Kazdopadne najradsej by som to neriesil – uzivatel moze mat vymyslim si kosik v session na jednej domene, na druhej by sa sice mozno nejako prihlasil, ale aby sa vytiahla aktualna session musel by som si zrejme posuvat session_id, pripadne ich dokonca asi ukladat v DB. Nenapada ma zatial nic pouzitelne. Celkovo sa mi ale nepaci ten koncept tych domen, toboz ak este bude obsah na tych domenach nefiltrovany podla jazyka.

retko

K duhemu problemu:

Zustat prihlaseny pri prechodu mezi ruznyma domenama je resitelne, defakto na tom principu jak jsi ho tu nastinil. Muzu ti zhruba popsat jak to dela Seznam (pokusim se to co nejvic zjednodusit, neni to uplne trivialni):

Je domena login.szn.cz, veskere prihlasovani probiha na ni. Uzivatel prijde na nejakou sluzbu, napr. sauto.cz, zjisti se ze neni prihlasen a presmeruje se na login.szn.cz. Tam se po uspesnem prihlaseni vytvori trvala session, zapise se cookies s rozsahem platnosti login.szn.cz a dale se vytvori do databaze ticket. Identifikator session je ulozen take v ticketu pro pozdejsi dohledani prislusne session. Casova platnost ticketu je minimalni, staci uplne minuta, po pouziti se hned mazou. Potom login server presmeruje na login.sauto.cz a v Url preda ID ticketu. Na login.sauto.cz vsak nenaslocuha aplikace sluzby sauto, ale opet tentyz prihlasovaci stroj, ktery sedel i na adrese login.szn.cz. Overi ticket a pokud vse sedi, nasaje data session z databaze a nasetuje cookies s rozsahem platnosti .sauto.cz. Ted uz jen presmeruje na stranku sluzby. Hotovo.

Kdyz pak prejde uzivatel na jinou sluzbu Seznamu, napr. lide.cz, ta zjisti ze uzivatel neni prihlasen a.. cely se to opakuje, s tim rozdilem, ze to projde transparentne*, pokud uz uzivatel prihlasen je.

Nezapomente myslet take na centralni odhlasovani, to je sessionu s kazdym pozadavkem overit jeji platnost, a kdyz je uz neplatna (uzivatel se odhlasil na jine sluzbe), odhlasit uzivatele i na aktualni sluzbe.

Sessions muze mit uzivatel samozrejme vice, do hry vstupuji faktory jako IP adresa, user-Agent, atd.)m takze odhlaseni na pocitaci v praci nas neodhlasi na pocitaci doma.

Tak enjoy ;)

retko

S tou transparentnosti je to ve skutecnosti jeste krapet slozitejsi (resi se tam napr. jeste uroven authorizace, nektere sluzby pozaduji vyssi uroven (napr. penezenka), tam se pak prihlasuje znovu a povysi se ta uroven), ale to sem nepatri, princip je myslim jasny. Diky tomuto mechanizmu, kteremu rikejme napr. „centralni login“, muzete prechazet mezi ruznymi sluzbami (na ruznych domenach) s jedinym prihlasenim.