Opera

És ha a http://www.example.com/delacc.php?c=true&s=confirmed címet hívja be?

Ez azért tényleg eléggé erõs lenne. 😄 Viszont semmi köze a sütikhez és aki ilyen oldalt csinál azt kezeltetni kellene. Vagy csak oktatni. 😄



RE: Te átírhatod a süti lejárati idõpontját...

De az Auth és a SESSID süti nem ugyan az. Utóbbi valóban munkamenet süti, böngészõ zárásakor törlõdik is. Csakhogy ezt Te hiába írod át 2012-re, attól még következõ alkalommal nem fogod tudni használni, hiszen a benne tárolt munkamenet azonosító már nem lesz érvényes, a szerveren nem lesz megtalálható a hozzátartozó munkamenet állomány. Az auth süti tartalmázhoz (külsõ oldalról) meg nem férhetsz hozzá, tehát kívülálló nem tudja magát újrahitelesíteni, ez mindenképpen zsákutca.



Az SG teljesen más, úgy látszik nem volt elég kifejezõ az erre utaló megjegyzésem. Az SG autentikációkor is ÉS munkamenet közben is ellenõrzi az adatokat. Az átlag bevett szokás csak az utóbbi használata, itt a különbség. Tehát SG-n ha megszerzed az auth sütit, semmit nem érsz vele, mert magát a belépést akadályozza meg, erre pedig általában nem ügyelnek a legtöbb oldalnál, mivel nem igazán van rá szükség. Az SG-n azért van, mert szinte bárki tetszõleges kódot juttathat be az oldalra.

A munkamenet közbeni ellenõrzés pedig azt jelenti, hogy közvetlenül a belépéskor/hitelesítéskor a munkamenetben eltárolod a belépett felhasználó IP címét és környezeti adatait, majd azt minden oldalon összehasonlítod az éppen új lapot lekérõ kérelem küldõjével, tehát minden oldalletöltésnél. Ezek olyan adatok, amik bár változhatnak, de nem egy munkamenet ideje alatt, így teljes mértékben lehet rájuk hagyatkozni.

Ha átírod az SID-t egy másik, éppen létezõ azonosítóra, akkor valóban jogosultságokat szerezhetnél, de mivel nem Te léptél be az oldalra eredetileg, hanem idõközben "loptad el" a jogosultságokat, így a Te adataid nem lesznek azonosokat az eredeti tulajdonoséval, így azonnal kidob és megsemmisíti az oldal az egész munkamenetet (mindkét félre kihatással).

Ez persze már múlik a programozón, de annyira alapvetõnek számít, hogy kb. vetekszik a fentebbi konzumidióta delacc.php párossal. 😄

RE: A biztonság témán kívül ...
Nem tudni, függ a letárolás típusától. Általában valamilyen adatbázisszerû (sokszor SQLLite) megoldásban használják, ilyenkor nem lassít semmit. Persze elõfordulhat olyan másfajta megoldás, ahol befolyásolhatja a sebességet is.

A cross-domain egy hatalmas biztonsági kockázatot jelent, Operában ezért van is alapból kikapcsolva az opera:config-ban, viszont sok hasznos userJS csak így mûködik. Ott van egynek a Gmail-t a Readerrel egybeolvasztó GM script.

"Rejtett iframe-ben ugyan beléptethet a külsõ oldal, csak a szülõoldal semmilyen adathoz nem férhet hozzá."

Ezt jó tudni. Úgy gondoltam, hogy mivel a userJS is ki tudja olvasni a sütiket/webstorage tartalmát, így az oldalon futó JS is. Mivel az viszont tény, hogy a használt userJS-eket tudja detektálni, ahogy itt is írják alul.

És ha a http://www.example.com/delacc.php?c=true&s=confirmed címet hívja be?
Tudom, ilyen szarul ritkán programoznak le egy oldalt, de azért elõfordulhat.

"Te átírhatod a süti lejárati idõpontját, marhára, semmilyen szerveroldali környezetben nem fog korlátlanul mûködni"

Azokra gondolok, ahol a munkamenet lejártakor (tehát a böngészõ újraindításakor) a login oldalra dob. Ezeknél üres a lejárati dátum. Ha beállítasz neki mondjuk 2021-et, akkor nem tudom pontosan meddig mûködik, de tény, hogy elõfordult már, hogy hosszú hónapokig nem kellett újra bejelentkeznem.

A Google Groups-on szintén tudtam manipulálni. Ott be volt állítva asszem 1 napra az adult content confirmation, de átírtam, aztán hónapokig mûködött az is.

Azt elismerem, több olyan oldal van, ahol ez nem járható út. Az SG is kidob IP váltáskor.

Régebbi phpBB fórumban már captca-t is játszottam ki vele, hogy átírtam a helyesen beírt captcha által adott SID lejárati dátumát, így az oldalra újra belépve a kitöltetlen captcha mezõ esetén is beengedett.

"ráadásul alapvetõ hogy legyen minimum egy IP és user_agent ellenõrzés, tehát szintén járhatatlan."

Sok minden alapvetõ lenne, aminek nem tesznek eleget az oldalak fejlesztõi. Auth süti sem mindenhol van. Mint mondtam találkoztam már olyan szar oldallal is, ahol két süti volt plain/text formában. A jelszó és a felhasználónév.

A biztonság témán kívül pedig: Kétlem, hogy jót tenne a böngészõ sebességének, ha a cookies4.dat csak hízna, hízna és hízna. Egy szimpla Google kereséssel egy rakás olyan oldal sütije tárolódik, amit amúgy soha nem is fogsz talán meglátogatni.

Ez nagyon nem így mûködik. Ez itt most nem a böngészõkrõl szól, még csak nem is igazán a weboldalakról, egyszerûen nem így mennek a dolgok, soha, semmilyen esetben sem. Kezdve azzal, hogy a cross-domain tiltás a sütikre is vonatkozik, ha tudnád egy süti nevét, akkor sem kérdezhetnéd le annak tartalmát, még a létezését sem tudnád megállapítani. Rejtett iframe-ben ugyan beléptethet a külsõ oldal, csak a szülõoldal semmilyen adathoz nem férhet hozzá. Bár erre lennének éppen módszerek, csak mivel a külsõ oldalnak kellene visszaküldenie adatot, így ez járhatatlan. A Cookie és a Session között nincs semmilyen kapcsolat, maximum az adattárolás. Te átírhatod a süti lejárati idõpontját, marhára, semmilyen szerveroldali környezetben nem fog korlátlanul mûködni, a munkamenetnek mindenképpen van egy idõtúllépése, utána újat ad neked. Ez pedig szintén független a sütiktõl, de még a leprogramozástól is. Az auth süti tartalmához meg úgysem tudsz hozzáférni csak úgy egyszerûen (meg kb. sehogy sem), illetve általában az is gyakran váltakozik. Az SID átírása jogos, csak éppen megkaparintani az SID-t nem olyan egyszerû (nagyon nem), ráadásul alapvetõ hogy legyen minimum egy IP és user_agent ellenõrzés, tehát szintén járhatatlan. Végsõ soron: törölheted az auth vagy az SID sütit, attól még szerveroldalon aktív marad egy ideig a munkamenet. Mellesleg az Opera süti törlése mitõl védene meg? 5 percenként kilépsz a böngészõbõl hogy folyamatosan törölje õket? Vagy minden új weboldal elõtt?

Nem lehurrogni akarlak, de a kommented szinte semmilyen megközelítésbõl sem állja meg a helyét. Viszont van pár jó gondolat is, például egy beszúrt link stílusbeállításainak vizsgálata, ez tetszett. Például ez tényleg így van, ez egy amolyan kiskapu is lehetne. Ugyanakkor nem tudod semmire sem használni, max. lekérdezed vele a közismert pornóoldalakat és még ezzel is elpöcsölne csomó idõt a böngészõ. 😊

A legmenõbb még az volna, ha az Opera megjegyezné, hogy melyik oldalon melyik szótárat szeretném használni.<#rolleyes>

Elvileg így is bennmarad néhány - lehet azért mert vannak betûkhöz rendelt keresõim? Mondjuk nem vészes annyira. (vagy vmit nagyon nem jól csinálok) Köszi azért 😊

640kb volt a .dat (és szerintem kb. 10.10 környékén telepítettem újra mindent, azóta gyûlt) - de most kézzel kipucoltam 😊

1: A cookie biztonság sokkal inkább az adott weboldal függvénye, mint a böngészõé. Cookie szerkesztéssel amíg le nem jár egy adott oldalra a session addig ha elõtte bejelentkeztél egy másik sessionnal, elég átírni a hosszú számsort valaki máséra és máris azzal jelenteztél be. A Freemail-nél nem meglepõ, pár éve még megoldható volt, azóta javították a sok kritika miatt.

De hogy a Google Groups-on egy screenshot (ami tartalmazta a címsort, benne a SID-et, ha akkor jelentkeztél be és a fõoldalon voltál) alapján, arra lecserélve a saját cookie-dban lévõt, bejelentkeztél (ezzel akár adminjogot is szerezhettél) az már durva.

2: Mivel ha csak a látogatott oldalról fogadsz el sütitket azzal sokkal nagyobb a szívás, mint ezzel a módszerrel, így a különbözõ ganaj API-knak köszönhetõen (lásd: Facebook, Twitter és ilyesmi, de azok legalább megkérdezik, mivel jogi szempontból kénytelenek) egy szimpla legálisnak tûnõ oldalra navigálva bejelentkeztél anélkül, hogy nem is tudsz róla, mert az 1*1 pixeles iframe-ben vagy jelentkezve. A jelszavadat ugyan nem szerzik meg, jó esetben a felhasználónevedet sem, de szabadon ténykedhetnek a fiókodban, amíg le nem jár a SID. Ha nem szinkronizálja szerveroldallal, akkor átírod a lejárati dátumot és akár örökre benn lehetsz az adott fiókban.

3: Ez már tényleg a legalja, de sajnos sok ilyen oldal van, ahol a sütik plain/text formában tárolják el még a jelszavadat is.

És végül, ami ugyan nem biztonsági kérdés, de ezzel a módszerrel stabil 10-20kB méretû cookies4.dat állományt kapsz, ellenben ha nem törlöd, akkor a pár hét alatt akár több megásra is meghízhat ez az állomány és akkor már olyan sok adverticum és minden szeméttel lesz tele, hogy vagy egy órán át szüttyögsz vele, hogy egyenként törölgeted a nem szükségeseket, vagy egy kattintással az egészet és utána jelentkezhetsz be újra és újra az összes oldalra.

Azt, hogy hol jártál a visited links-es tényezõ alapján kérik le, süti alapján nehéz lenne, ugyanis a tárolt sütik listáját nem kérheti le egyetlen oldal sem a böngészõtõl, maximum találgathat, hogy ha õ rákeres, hogy a látogatók közül x oldalon kik jártak, akkor nálad megtalálja x oldal sütijét. De ehhez még a Google is kevés lenne, hogy az internet összes oldalának sütijére rákeressen, hogy megtalálható-e az adott látogatónál.

De ha nincs Visited Links egy oldalon (ami userCSS-vel pótolható és így kliensoldalon történik minden, tehát nem tudja lekérni a startpanic.com oldal sem), akkor csak a referrer oldalt (vagyis amirõl közvetlenül érkeztél, ha az <a href-es linkre kattintottál valahol) látja. De ha könyvjelzõbõl vagy vágólapról érkeztél a linkre, akkor nem látja, mivel nincs.

milyen biztonsági ok indokolja, hogy töröljek egy cookiet? azon már túllépett mindegyik böngészõ, hogy azon át támadható legyek - az meg, hogy merre jártam a neten nem titok, nézegessék 😊

Beállítod, hogy Új sütik törlése kilépéskor.
Ha ezt néhány oldalon felül szeretnéd bírálni, akkor pedig az adott oldalon jobbklikk->Oldal tulajdonságai->Sütik és ott kiveszed a törlés mellõl a pipát.

Ezt követõen az override.ini fájlod fogja tárolni, hogy melyik oldalakon tartod meg a sütiket.

Kikeresed a profile mappádból a cookies4.dat-ot és letörlöd.

biztonsági okokból

Úgy érti mi a francnak törölgetni.

de nem értem 😊 a cookie-k nélkül sok oldal egyáltalán nem hajlandó mûködni, csak van olyan, amihez neked is kell cookie, így te is foglalkozol vele. vagy nem? mindent cookie nélkül?<#wow2>

minek?

😊 és miért nem?

nincs ötletem, nem szoktam ilyesmikkel foglalkozni.

kétszer Opera, derekas szombat reggel.

Hogyan érhetném el, hogy az Opera minden cookie-t töröljön az Opera kilépés után? Beállítottam, hogy from the sites i visit, meg hogy az újakat törölje, de a Google néhány cookie-ja így is megmarad.

Köszönöm.

Ha a GUIt javítgatják akkor az átlátszóság bugot is kijavíthatnák. 😊

ctrl+f12 -> keresés

Itt amelyiket akarod arra szerkesztés - részletek - gyorshívó keresõmotorja

Sziasztok! A gyorshívó ablakban az Ask keresõt át lehet valahol állítani másra?

Az MSI telepítõ leszedi a korábbi verziót és úgy telepíti fel az újabbat, tehát normál esetben nincs szükség uninstallra.

Ismétlem, normál esetben, ha a telepítõ bugos és nem szedi le a korábbi verziót vagy összekavarodnak dolgok, akkor célszerû, de ilyen ritkán van és csak olyan alfáknál, ahol nagyot lépnek elõre (például 10.10 -> 10.50).

Ezt a 10.60-at úgy kell venni, mint a 10.5x széria béta 2-jét. Még vannak benne bugok, de már igazából csak a GUI-t csiszolgatják. Állítólag lesznek még HTML5 és CSS3 implementációk, de az már nem vészes annyira. A motor verziószáma sem ugrik már nagyot és hardvergyorsítás is csak a 11-es verzióban lesz.

Nem kell a 60-asokon belül, de megteheted nem árt nem használ.

Letöltöd és elindítod a telepítõt . Csak a nyilvános kiadások (béták és végleges ) Frissülnek automatikusan a snapshot-ok nem .

erre hogy frissítsek? megint töröljem a mostani verziót?😄 mert látom frissíteni nem lehet operából 😮

Van már újabb snapshot is 😊

Ma még alpha , holnap beta , pár nap múlva RC <#circling>

tényleg gyorsabb, és gyorsabban is indul😊

A Vezérlõpult programok hozzáadásánál elõször telepítsd le, mert különben 2 telepített Opera verziót mutat. A személyes beállításaid így is megmaradnak.

leszedjem a 10.53-as operát és rakjam fel ezt a verziót, vagy simán mehet egybõl fel ez a verzió?

Nekem az 53-as sem omlott. Olvastam hogy sok bug van benne, de én nem tapasztaltam. Ha ez a 10.60-as ALFA, akkor milyen lesz a végleges ? 😊))

Nem béta, hanem alfa.

Rage47: Ha azt vesszük alapul, hogy az egész 10.5x széria egy bughalmaz és ebben (legalábbis ebben csak a motorral kapcsolatban, az eggyel korábbiban) 6 ismert bugot javítottak, köztük két olyat, ami összeomlást is okozott, így már csak 29 van, tehát ajánlott a frissítés.

Teljesen stabil - végleges szinten van.

bétát nem akarok felrakni 😊

Mekkora szerencse hogy az egy másik mappában tárolja, illetve nem is limit nélküli. <#gonosz1>

Nem. Attól ekkora, hogy nem limitált a cache mérete, tehát pár napos böngészés után 800 megát foglal el a rendszerpartíción.

Pontosan, ezeket is leírtam Chrome topikban. Amit linkeltem az offline installer, netkapcsolat nélkül telepíthetõ. A letöltögetõs telepítõ az olyan ~500KB körül lehet.

ha az oldalinfot meg a flasht nem építenék bele, az se lenne több 20 megánál 😊 fura dolgok ezek a böngészõk

a legszebb amúgy anno az IE8 telepítõ volt, ami 3-4 mega... aztán telepítéskor leránt vagy 50 megányi frissítést magával, plusz a Windows Update-en rögtön igényel pár vödörnyi hozzávalót... viszont máig se tudni mekkora végül is a böngészõ.

na, hát azért néztem😊

és ez felmegy netkapcsolat nélkül, vagy akkor tölt még hozzá? mert nagyon nem mindegy.

az lehet, de itt nem annyi van letöltve

hát igen, ebbõl a szempontból jóval nagyobb a Chrome - bár ahogy Ability is írja csomó, igazából nem konkrétan a böngészõ részét képezõ rész is benne van (ha jól tudom már egy egész Flash is!). de mindenképp nagyobb, egy nyílt forráskódú, alapvetõen modulokból felépülõ programnál ez általános... az Opera meg egy nagyon kompakt, optimalizált rendszer.

Chrome v6 beta installer mérete Windows platformon: 17MB.

Plusz Opera nem tölti le az összes nyelvi szótárt és lokalizációt (utóbbit bizonyos kiadásoknál). Nincs benne voiceover támogatás, nincs benne háromféle audio- és videocodec, a DragonFly is érdekesen van implementálva, mintha egy külsõ oldalt hívna be, akkor amit te is mondtál nem tárolja el az elõzõ frissítéseket, nem tárolja helyben a károsnak nyilvánított oldalak listáját.

Végeredmény: nincs értelme összehasonlítani, sosem volt. Nem is értem kinek számít egyáltalán pár MB eltérés.

rendben (mondjuk így a chromenál az installer mérete 53mb, operánál 12mb-ot tölt le)

maximum a telepítõ (ha egyáltalán van letölthetõ, és net nélkül is feltelepíthetõ változat) méretét lehet összehasonlítani, mert mindkét böngészõ másképp épül fel - a Chrome egyszerû, viszont közvetlen telepítéskor (és/vagy azután) rögtön aktívan töltöget le, pl. a biztonsági fileokat helyben (is) tárolja. az Opera nem tárol ilyesmit offline, minden kérésnél rápillant a biztonsági adatbázisokra.

A krómos kiterjesztések meg... hát, egyelõre talán 0 van, amelyiknek van értelme - az adblock letölti a reklámot aztán kitakarja (nem engednek mást) - így nem spórol semmit, az egérmozdulatok nem mûködnek pl. belsõ oldalakon (ha jól emlékszem https-es oldalakon sem), nem lehet testre szabni velük részletesen a mûködést, és már (régebben volt) nincs lehetõség UserJS-ek szabad futtatására, beépítésére.

Nem cáfolatról beszélünk, mert elõször azt kellene megnézni hogy akkor mi a böngészõ alapmérete
A funkcionalitásban meg lehet nézni a böngészõk összes dolgát, ergo a kiterjesztéseket is 😊

Mi egyebet tudnék mondani, ha nálam egyszerûen nem így van, még itt az Opera topikban is téged cáfoltak, a két böngészõ mérete közel azonos. Ezen felül az Opera sokkal elõnyösebb, mert funkcionalitásban köröket ver a Chrome-ra. Ez elfogult?

Elég elfogultan szemléled a dolgokat, de nekem ehhez nincs hozzáfûznivalóm😊
Már mondtam hogy nem a tárolandó adatok érdekeltek