Böngésző azonosítás
We want to serve you and not track you.
Akár ez is lehetne a mottója a gondolatmenetemnek, ami már hosszú ideje érlelődik bennem. Mivel az évek során egyáltalán nem láttam, hogy bárki is, akárcsak javaslat szinten érdemben foglalkozott volna a témával (ennek ellenére simán elkerülhette a figyelmemet), gondoltam, én most itt szűk körben kifejtem, mi a problémám a jelenlegi helyzettel, és hogy kiindulásképp miben látnám a megoldást. Aztán ebből hátha kikerekedik egy olyan konstruktív vita, amit majd akár nemzetközi szinten is érdemes lesz folytatni. Vagy nem.
Nem kizárt, hogy az írásom hagy majd kívánnivalókat maga után szakmailag (is). Ezért kérem, hogy ha az inger-mérőtök eléri az „irritáló” jelzést, akkor úgy olvassátok, mint egy hirtelen felindulásból elkövetett értetlenkedést, és legyintsetek reá. Köszi.
Az alapprobléma
Szerintem itt mindenki tisztában van vele, hogy mi is az a User-Agent
sztring, mire hivatott, és hogy mire nem alkalmas. De azért röviden felvázolom az én meglátásaimat.
Íme egy példa a valós életből:
Mozilla/5.0 (iPhone; U; CPU iPhone OS 5_1_1 like Mac OS X; en) AppleWebKit/534.46.0 (KHTML, like Gecko) CriOS/19.0.1084.60 Mobile/9B206 Safari/7534.48.3
Mit is látunk itt? Egy iPhone-on futó, Webkit alapú böngészőt. Tapasztaltabbak azt is tudják, hogy Google Chrome az illetékes. Plusz látunk egy tonna felesleges adatot:
Mozilla/5.0
– ezt komolyan használja még bármi is bármire? Mire jó? Ezt annó a Netscape vezette be, és az IE lemásolta, mert azt látta, hogy sokkal több oldal működik, ha ez ott van, mert már akkor is divat volt a szelektálás. A 90-es évekről beszélek…- Jön egy katyvaszos, zárójeles rész, ami az eszközt és az operációs rendszert hivatott azonosítani, több-kevesebb sikerrel. Androidoknál vannak aztán az igazán cifra dolgok.
- Ezt követi a megjelenítő motor név és verzió,
- és a miheztartás végett zárójelben megmagyarázza a dolgot, hogy legyen mihez viszonyítani. Elvégre „a Trabant is olyan, mint a Porsche”… Csudijó. Ez se jó semmire.
- Jön a böngésző verziója, de bárcsak szabványos lenne mindenhol… Persze nem az. És nem is egyértelmű. A példánál maradva a CriOS-ről talán a legutolsó utáni helyen gondolnám azt, hogy a Google Chrome-ról van szó.
- Végül megint egy csomó adat, ami leginkább csak arra jó, hogy a böngésző detektáló reguláris kifejezésünkbe egy újabb kitételt tegyünk, mert ez nem Safari.
Mi ezzel a probléma?
Az, hogy csak arra nem jó, amire kellene, hogy legyen: eszköz–rendszer–böngésző egyértelmű megállapítására, nyomonkövetésre és felhasználó azonosítására alkalmatlan módon. Bár ez utóbbi többnyire most is teljesül, előbbire sokszor csak komoly megalkuvás árán alkalmas.
Kliens oldalon ugyanúgy lehet csak detektálni a böngészőt, mint a szerver oldalon: a User-Agent
sztring reguláris kifejezéssel történő mintaillesztésével. Persze kliens oldalon jobb esetben oda van rakva a navigator
tulajdonság, ami azonban annyit ér, mint puskagolyónak az integetés.
Miért van szükség a változtatásra?
Manapság nem hagyhatjuk figyelmen kívül az újnak éppenséggel nem mondható alternatív böngészési megoldásokat, melyeket az egyre-másra felvonultatott készülékek hoztak be a mindennapokba.
Saját tapasztalatból tudom, hogy a reszponzív megközelítés nem minden esetben követhető, és egy-egy megjelenítési forma bizony megköveteli, hogy külön sablonokat, sőt, egyes esetekben külön alkalmazást is kapjon.
Nekem (és akkori kollégáimnak) az alkalmazást többek közt az eszköz, annak felbontása és a futtatott böngésző figyelembevételére is fel kellett készítenünk.
Nem volt mindegy, hogy mobil, tablet vagy tévés eszközről van-e szó. Sőt, még a játékkonzolokra is figyeltünk egy időben. Ezt a mai napig sem lehet egyértelműen meghatározni. A felbontást és a képpontsűrűségi szorzót pedig még ha sikerül is pontosan visszakapni, akkor sem biztos, hogy mit kell megjeleníteni, ha az eszközt nem sikerült beazonosítani. Hány esetben fordul elő még a mai napig is, hogy a telefonnak sokkal nagyobb a felbontása, mint mondjuk egy tévére köthető médiabox böngészőjének? Nem beszélve az okostévék elég gyenge processzorral megtámogatott beépített csodáiról.
Az sem volt mindegy, hogy milyen böngésző. Mert bár túlnyomó többségben Webkit-alapú böngészők uralkodnak, de ezen belül lehet Safarival, Chrome-mal, Dolphinnal vagy egyéb szakadár böngészővel vagy csak simán az Android alapértelmezett böngészőjével is dolgunk. A CSS és JS támogatottsági problémák csak a kezdetet jelentették. De amikor a websocketnek a Safari és a Chrome különböző verzióját támogatta, és emiatt kétféle módon is kellett szerver oldalon (bitenként) feldolgozni a csomag-fejléceket, na az fincsi volt.
A sort még lehetne folytatni, a lényeg, hogy számos olyan szolgáltatás van, ami napi szinten szenved egy apróság miatt, amit még csak igazából különösebb erőfeszítésbe sem kerülne mindenki által elfogatott formára hozni és szabványosítani.
Mire lenne szükség?
Szerintem égető szükség van a User-Agent
sztring teljes megreformálására a JavaScript navigator
interfészével egyetemben. Az elképzelésem szerint az új azonosító minden egyes blokkja egyértelműen megfeleltethető lenne a navigator
interfész új tulajdonságainak. Ezt követően pedig nem lenne semmi akadálya, hogy a szerver oldali nyelvekben is megjelenjen egy erre épülő modul. Én mindezt a következők szerint képzelem el:
navigator.device.type
- A készülék típusa (például:
desktop
,mobile
,tablet
,TV
,game console
) navigator.device.manufacturer
- A készülék gyártója (Dell, Lenovo, Apple, Samsung)
navigator.device.model
- A modell (populáris) elnevezése (ThinkPad, iPhone, Galaxy S3)
navigator.device.number
- A modell száma, ha van (I8190, iPhone 6, XS15)
navigator.os.name
- Az operációs rendszer (Apple iOS, Google Android, Microsoft Windows)
navigator.os.version
- A verzió (6.0, 4.4.2, NT 6.0)
navigator.os.language
- A nyelv (
en
) navigator.browser.name
- A böngésző neve (Safari, Chromium, Opera, Internet Explorer, Dolphin)
navigator.browser.version
- A böngésző verziója
navigator.browser.language
- A böngésző nyelve (mert eltérhet az operációs rendszerétől)
navigator.browser.engine
- A megjelenítő motor (Trident 6, Webkit 534.46.0)
A lista persze nem feltétlenül teljes, szinte a végtelenségig lehetne finomítani avagy bonyolítani, én csak azt az érzésem szerint szükséges minimumot vázoltam fel, amivel egyértelműen meg lehet mondani egy a webszerverre beérkező kérésről, hogy kiféle-miféle forrásból származik.
Ezek alapján a fenti példa a következőképpen nézne ki (akár):
Mobile, Apple iPhone 5, Apple iOS 5.1.1 en, Chromium 19.0.1084.60 en, WebKit 534.46.0
Így szerintem a teljes formájában is sokkal informatívabb. És ha így lenne, akkor nem kellene brutális méretű adatbázisokat fenntartani, és nem kellene erőforrászabáló reguláris kifejezés osztályt írni sem. Nem kéne saját magunk útjába akadályokat görgetni.
Nektek mi a véleményetek?
■
+1
ha jól értem: eszköztulajdonság dekl. vs megjelenítés
Ezt ennyire speckó módon sztem nem lehet belőni, mert ezek közt sok átfedés is lesz. Gondolj csak azokra az eszközökre, amik egyik kategóriába sem sorolhatóak egyértelműen. Pl olyan mobil eszköz, ami dokkolva van és a megjelenítés monitoron/TV-n történik.
Itt máris nem tudod a megjelenítést helyesen a megjelenítő eszközhöz igazítani, mert "Sammtung Sun 4"-ről megy a http kérés, azt mégis egy 30"-os UHDTV-n nézik :)
De szinte lehetetlen - és a tulajdonosnak üzletileg sem érné meg - ha ezekre az (egyébként folyamatosan frissítendő és bővítendő eszközinformációkra), kellene felkészíteni egy-egy felületet (pláne visszamenőlegesen is).
--
Azt most hirtelen nem tudom, hogy pl a http fejlécekben van-e / lehet-e / tud-e / érdemes-e olyan információ, ami csak a mobil és asztali böngészést különböztet meg hálózat használat szempontból: ebben a kontextusban a mobil/desktop közt például csak annyi különbség, hogy az első az oldalletöltés költséggel/sávszélproblémával jár (mobilnet), a másik pl kábelen külön költség nélkül.
--
User-Agent:
content negotiation:
Ez alapján a cél alapján valóban lehetne szépen csiszolni a fenti sztringen.
--
Azt tudnám még elképzelni, hogy a megjelenítési arányokat, felbontásra vonatkozó információkat lehetne pontosítani, a böngésző csapná hozzá a kéréshez az OS megjelenítési (és a böngésző ablakméretei) beállításai alapján és másik oldalon - amennyiben erre szükség van - pedig párosítani css/html oldalon (de akár más tartalmat kiszolgálni ugyanazon az url-en).
Ez mondjuk most is részben elérhető, de külön hekmány kell pl a képek kiszolgálásánál (lásd img##kukac##2x.png és hasonlók).
De lehet hogy ez is annyival megbonyolítaná/megdrágítaná a megjelenítések kialakítását, hogy csak kevesek használnák ki.
De ha már változna...
A példánál maradva a
Chrome on iOS. Egyébként nem lenne ildomos odaírni, hogy Chrome, mert nem az, ugyanis a böngésző motorja teljesen más, mint más platforomokon, elvégre ez csak egy Chrome bőrbe bújtatott Safari.
Az én hibám...
Nekem meg a CryoPrison a
Puszty búgyet
Sok éve olvastam egy cikket,
Pedig az a javaslat nekem logikusabbnak tűnt. Csupán úgy kellene az érték kinézzen mint más összetett adatot tartalmazó fejlécek esetében, például
Content-Type: text/html; charset=utf-8
. Ez alapján a te példád így nézne ki:device-type=Mobile;
device-manufacturer=Apple;
device-model=iPhone;
device-number=5;
os-name="Apple iOS";
os-version=5.1.1;
os-language=en;
browser-name=Chromium;
browser-version=19.0.1084.60;
browser-language=en;
browser-engine="WebKit 534.46.0"
Tetszik
Köszönet a moderátornak
Ezért van a szerkesztő :)
Amellett, hogy a kuka által
Itt azonban felmerül a kérdés, hogy ildomos-e ilyen mennyiségű adatot minden kéréssel utaztatni. Esetleg érdemesebb a szervernek kezdeményeznie egy feltételes átirányítást a számára releváns képességek alapján:
Ha kívánságműsor...
1) Az Android isActiveNetworkMetered mintájára egy boolean ami megmondja, hogy a user forgalmi díjas kapcsolaton netezik-e (olyankor nincs gyomrom retinára optimalizált bitmepeket küldeni).
2) Kijelző való élet beli átmérője (inch/cm) - egyértelmű okokból.
Teljesen egyetértek.
Továbbgondolva a témát szerintem nincs értelme azzal foglalkozni, hogy mi a gyártó, vagy hogy milyen verziójú a motor, ami a böngésző alatt van. Ehelyett capability-re kellene koncentrálni inkább. Erre js-ben már vannak összetákolt kódok, amik lekérdezik, de mennyivel jobb lenne ezt az információt már a header-ben megkapni,
pl:
-
html-version: 5.0;
-
css-version: 2.0; additional-selectors=checked,disabled; etc...
-
js-version: 1.8.5; ajax=1; ajax-impl=active-x-6; websockets=1; webworkers=1; push-state=1; etc...
-
display: touch; 1920x1080; 10"; 3d; etc...
-
network: 3g; limited-speed-preferred; etc...
Mert igazából erre vagyunk kíváncsiak.
Ezt akár accept típusú header-ben is lehetne küldeni, vagy prefer header-ben. Nyilván ennél az 5 perc alatt összedobott változatnál jóval kidolgozottabb szabvány kell, pl nem csak whitelist, hanem blacklist is. Kapásból a szabványra lehetne írni js és szerver oldali feldolgozókat, amik kinyerik ezekből az adatokból, hogy mire képes a böngésző, és mire kell optimalizálni a kimenetet. A legtöbb dolgot, amit most js-ben csinálunk ezek miatt, ugyanúgy meg lehetne oldani szerver oldalon is, ha lennének ilyen header-ek.
Tippre a W3C lesz az, mert ez
IETF.
Ja nekem is úgy rémlett, hogy
Míg válaszolnak...
Jelenleg én úgy gondolom, hogy nem feltétlenül kell a kliens oldalt kisebb-nagyobb bonyolultságú js-el terhelni. A useragent stringet megkapod szerveroldalon, ezzel mindenki annyit kezd, amennyit éppen tud. Ha "mobil" megjelenést preferál az eszköz, akkor 99%-ban benne van a "mobile / Mobile" szó. Ez persze még édeskevés önmagában.
Viszont meg kell adni (jól látható linkkel, menüvel) a lehetőséget a látogatónak, hogy változtasson a nézeten. (Ez a véleményem valószínűleg akkor is fennáll, ha történik szabványfejlesztés az ügyben.)
És el kell menteni min. egy sütibe, hogy ha már egyszer beállította, mindig azt kapja, míg nem vált újból.
Érdemes lehet még tárolni a stringet a kért beállítással, ezek statisztikája alapján akár automatizáltan is lehet fejleszteni az eszközfelismerést, ill. a hozzá tartozó megjelenés kiválasztását.
A süti jó ötlet akkor is, ha
elvétve...
Pl opera mini proxyn,
Gyenge proci / ram,
Más (sok) JS is fut,
Lehetne sorolni sokat.
Ez - szerintem - tipikusan szerver feladat. De épp most indul egy nagyobb projekt, amiben meg kell oldanom, remélem lesz időm beszámolni róla.
Hajrá! :-) Hát a
Hát a legegyszerűbb szerintem a felhasználóra bízni egy külön fülön, hogy melyik változatot preferálja:
- js vagy csak html (kevesebb funkcióval)
- mobilra, tabletre vagy pc-re optimalizált
Lehetne betenni egy olyat a kezdőoldalra, hogy válasszon a lehetőségek közül, aztán utána cookie-ban elmenteni. Nyilván az sem 100%-os, de jobb, mint a semmi.
kezdő oldal
A kezdő oldalt úgy értettem,
Nem kell Redirect
és mi van akkor...
link?
Akkor add át az alkalmazásodnak a szükséges adatokat. Nem feltétlenül PHP az sem.
Nem tudok linket adni
Valami ilyet kell elképzelni.
külön domain
Én viszont csak view réteget cserélek és ehhez nem kell al domain, jobb a session és / vagy süti.
Jó doctype és Google is szereti.
Egy ideje egy csomó oldal
(
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2288.8 Safari/537.36
)Vicces ez a user agent, a
Az csak egy gügye Chrome. A
Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/39.0.2171.65 Chrome/39.0.2171.65 Safari/537.36
csúnya...
Nem lehet elég jó felismerést csinálni, mert szinte naponta jön ki újabb agent string.
Ezen kívül hagyni kell dönteni is a látogatót.
Featúra kérelem
Hát remélem lesz belőle
Ami még érdekes, hogy mindenki fully supported-et ír ES5-re, aztán pár napja találtam olyan bug-ot - Object.defineProperty-vel kapcsolatban - ami egyedül firefox-ot nem érinti. Egyébként maga a szabvány is gányolt ezzel kapcsolatban, 10x jobbra meg lehetett volna csinálni az egészet. Szerintem alapvetően ott van a gond webfejlesztésben, hogy nincs beleszólásunk a szabvány kidolgozásába. Összeül max egy tucat ember, összetákolják, aztán letolják mindenkinek a torkán. Baromi ritka az olyan szabvány, ami nyílt, és bárki ötletelhet (személy szerint csak egyet ismerek).
es-discuss, bárki szabadon
Object.create-el létrehozott
Köszi a linket, valószínűleg küldeni fogok bele pár dolgot.
Egyébként szerintem nyugodtan
Kíváncsi voltam, mit
Ajánlják, hogy legyen szabványos, aminek van alapja, csak akkor meg sosem lesz belőle semmi.
Természetesen összerakhatnak
Leírtam én is a véleményemet.
Kb én is ugyanoda jutottam, a
(Hát ez gondolom egy jó hosszú beszélgetés lenne a mailing list-en, ha nem próbálnak meg azonnal lekoptatni. Nekem a személyes tapasztalatom, hogy még ha meg is győzöd őket, hogy ez meg ez tök jó lenne, ha benne lenne a szabványban, akkor is általában az van, hogy de mégsem tesszük bele, mert csak. Nekem személy szerint erre most nincs időm, de ha gondolod vedd fel velük a kapcsolatot, hátha sikerül elintézni.)
"Üljünk össze"
Már csak azért is, mert a reakciók sokkal kevésbé voltak elutasítóak annál, mint amit vártam.
Szerintem két részre kéne
Én azt javaslom, hogy először
A pozitív döntés érdekében
Végülis úgy tiszta legalább,
Én javaslum a user-agent2 helyett a capabilities-t vagy hasonlót elnevezésnek.
A másik, ami benne szokott lenni ezekben:
SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL in this
specification have the meaning defined in [[!RFC2119]].
Félig off
Ha elküldenénk a net típusát, akkor mobilra olyan kódot küldhetnénk ki, ami a fentebb leírt módon működik, korlátlan netnél meg kiküldhetnlnk minden képet.
Engem legalábbis nagyon irritál az a trend, hogy görgetés közben töltődnek be a képek, akkor is, ha desktop PC-n nézem, korlátlan nettel. Igénytelennek tartom, amit tovább ronthat, ha a képek méretét nem küldik ki, azaz miután a böngésző letöltötte, megjelenik, de a mellette lévő szöveg átformázódik, a tartalom lefele csúszik.
Már azzal is sokat lehetne segíteni a dolgon, ha nem akkor kezdenénk el letölteni a képet, amikor bekerül a képernyőre, hanem mondjuk egy képernyővel korábban, így mire odaérek, már ott lenne, és sokkal jobb lenne a felhasználói élmény.
Ad extremum a böngészők mobilinternet esetén JS nélkül is automatikusan végezhetnék a képek betöltését (azaz addig nem töltik le, amíg nem látszik, mondjuk az előző bekezdésben leírt algoritmus alapján).
13
Kicsit továbbvittem
korlátlan?
És ugyan lehet, hogy korlátlan a net, de rossz a jelerősség telefonon vagy WiFin. Ekkor is inkább töltsön le több Mb adatot, amikor ISDN-nél vagy EDGE-nél nem gyorsabb a letöltés? Hogy változna mindez, ha változnak a körülmények letöltés közben?
Ezt nagyon nehéz általánosítani, ezért senki sem teszi.
Pl. be lehetne állítani az
beállítani
Akkor úgy kell neki
Beállítani
Elképzelhető, hogy van ennél
Ha nem tetszik, ne használd.