ugrás a tartalomhoz

Firefox autocomplete=“off” JavaScriptből

Joó Ádám · 2009. Aug. 14. (P), 17.41
Ma már minden böngészőben alapfelszereltség a jelszókezelő, azonban lenne még hova fejlődni ezen a téren is, néha pedig kifejezetten keresztülhúzza a fejlesztői szándékot a jóhiszemű, de buta önkitöltő.

Minden kényelmi velejárója mellett előfordulnak olyan esetek, amikor nem kívánjuk, hogy a jelszókezelő előre kitöltse a mezőket, ilyen lehet mondjuk egy beállítások oldal, ahol egyebek mellett opcionálisan a jelszó is változtatható.

Felhasználóbarát fejlesztő természetesen nem rögzít jelszót megerősítés nélkül, így rögtön egy második password elem is bekerül mögé:

<form method="post" action="">
    <dl>
        <dt><label for="password">Jelszó</label></dt>
        <dd><input type="password" name="password" id="password" /></dd>

        <dt><label for="password_confirm">Jelszó ismét</label></dt>
        <dd><input type="password" name="password_confirm" id="password_confirm" /></dd>

        <dt><label for="email">E-mail</label></dt>
        <dd><input type="text" name="email" id="email" value="kispista##kukac##example.com" /></dd>

        <div><input type="submit" value="Küld" /></div>
    </dl>  
</form>
Pandánk szolgálatkészen ki is tölti az első mezőt, elvégre azt belépéskor megjegyezte, a másodikat azonban üresen hagyja, aminek egyenes következménye lesz, hogy ameddig ki nem tölti a felhasználó, addig nem tudja menteni beállításait. Szó mi szó, biztonsági intézkedésként nem utolsó, de az esetek többségében a felhasználói élmény talán mégis inkább élvez prioritást. (Ha a másodikat is kitöltené, sem volna ideális, lévén a probléma megoldódna, de két mezőnyi felesleges adatforgalmat, feldolgozást és adatbáziskérést emésztene fel, ezen túl pedig minden profilmódosításkor sima szövegben utaztatnánk a felhasználó jelszavát.)

Az Internet Explorer egyik legérdemesebb találmánya az autocomplete tulajdonság, mely ugyan nem szabványos*, de rendkívül praktikus.

Mivel ragaszkodunk az érvényes HTML-hez, így – lesütött szemmel, és magunkban már mormolva is a penitenciaként kiszabott Miatyánkokat – csak a DOM-ba fogjuk beleszemetelni:

$(document).ready(function () {
    $('#password').attr('autocomplete', 'off');
});
Ez azonban nem működik. Minden bizonnyal előbb kerül kitöltésre, mint hogy attribútum deklarációnk érvényre jutna. Logikusnak tűnik a következővel próbálkozni:

$(document).ready(function () {
    $('#password').val('');
});
Ennél azonban úgy tűnik később kerül kitöltésre.

Egy nemrég blogmarkolt bejegyzésben azt javasolják, késleltessük a törlést:

window.setTimeout(function () {
    $('#password').val('');
}, 100);
Ez azonban csúnya, nem túl megbízható, és a felhasználó is észleli a felvillanó jelszót.

A megoldással gex szolgált a megjegyzések közt. Az űrlapunkat ki kell egészítsük egy azonosítóval, majd az űrlapon belül elhelyezni a JavaScriptet:

<form method="post" action="" id="login">
    <dl>
        <dt><label for="password">Jelszó</label></dt>
        <dd><input type="password" name="password" id="password" /></dd>

        <dt><label for="password_confirm">Jelszó ismét</label></dt>
        <dd><input type="password" name="password_confirm" id="password_confirm" /></dd>

        <dt><label for="email">E-mail</label></dt>
        <dd><input type="text" name="email" id="email" value="kispista##kukac##example.com" /></dd>

        <div><input type="submit" value="Küld" /></div>

        <script type="text/javascript">
            $('#login').attr('autocomplete', 'off');
        </script>
    </dl>  
</form>
Ízlés szerint persze közvetlenül a body végére is kerülhet.

* A HTML5-től azonban már az: http://dev.w3.org/html5/spec/Overview.html#the-autocomplete-attribute
 
1

jquery

Drawain · 2009. Aug. 16. (V), 19.15
Annyit szólnék hozzá, hogy a fenti kódok JQuery library segítségével íródtak, ha valakinek nem lenne világos.

Egyébiránt köszönjük a bejegyzést.
2

onkeyup és autocomplete kapcsolata

lacy · 2009. Aug. 17. (H), 08.55
én az autocomplete='off' beállítást azért használtam anno a lacy.hu regisztrációs oldalának megírásánál, mert a böngészők a felhasználónév és email cím begépelésénél felkínálta azokat a lehetőségeket, amiket a user már más weblapon megadott és szokott használni. a kisebb baj ezzel az volt, hogy nem tetszett(!) a nagyobb baj, hogy ha az így kapott ajánlásból választotta ki a felhasználó a nevét, email címét, akkor az input mezők onkeyup eseménye nem hajtódott végre, hisz nem ők gépelték kicsi kezükkel be a betűket. az én regisztrációs űrlapom ugyanis minden leütés után ellenőrizte a szintaktikát és a nicknév/email cím elérhetőségét (ajax), ami lehet elsőre hülyeségnek hangzik, de meglepően gyorsan működik. (ha nem tölt a user pornót közben :P)
3

onsubmit

gex · 2009. Aug. 17. (H), 09.51
ez nem csak elsőre hangzik hülyeségnek hanem másodszorra is. teljesen felesleges minden karakterleütés után ellenőrizni, ez rengeteg erőforrást emészt fel mind a kliens- mind a szerveroldalon. onsubmit a te barátod.
4

hülyeség nem hülyeség

lacy · 2009. Aug. 17. (H), 10.21
ismerem az onsubmitot és társait is. fölösleges vitatkozni azon, hogy hülyeség nemhülység, nekem ez tetszik.:) egyszerűen tetszik, ha már a gépelésem közben látszik, hogy az adott sor ki van pipálva vagy nem. erőforrási kérdések alatt nem tudom mire gondolsz, de a mysql_connect parancs olyan 0.005 másodperc alatt szokott lefutni, a lekérdezés is minimális, a legegyszerűbb select a világon, nem látom a sok erőforrást. ráadásul nem olyan oldalról beszélünk, ahol 10000 látogató van egyidőben a lapon, és főleg nem regisztrálnak egyszerre mind.:)
5

én kérek elnézést

gex · 2009. Aug. 17. (H), 10.47
nem látom a sok erőforrást
ja akkor bocsánat.
6

ne kérj elnézést :)

lacy · 2009. Aug. 17. (H), 11.08
ha tudsz valamit mondd el kérlek! :) az én esetemben ez egyáltalán nem lassítja a lapot, nyilván egy agyonra terhelt szervernél ilyet én se vállalnék be, de tényleg érdekel, hogy hol a sok erőforrás használat...
7

erőforrás

gex · 2009. Aug. 17. (H), 20.22
ezen nem kell sokat magyarázni szerintem. kitöltöttem a regisztrációs oldalt és 40 ajax kérés indult a szerver felé. néha egy későbbi leütés utáni kérés eredménye előbb tért vissza mint az előtte lévőé. ha ez nem erőforráspazarlás akkor mi?

az már csak hab a tortán hogy js nélkül nem lehet elküldeni az űrlapot, tehát ha én meg akarom óvni magam és a gépem/netem/stbm az ilyen fejlesztői f*szságoktól (bocs) akkor esélyem sincs regisztrálni.
8

+1, és egy kérdés lacy-hoz

solkprog · 2009. Aug. 17. (H), 20.42
gex-nek totál igaza van. De ha kicsit megerőltetem magam akkor azt meg tudom érteni hogy minden karakter után leellenőrized hogy nem-e foglalt az a név amit eddig beírt.
De arra azért kiváncsi vagyok hogy egy jelszókitöltés közben minek kell szerverhez fordulni? Szerveren ellenőriztetted le hogy egyeznek-e a jelszavak? Nem lehetne azt JS-ben is megoldani? Mert ennél a pontnál tényleg átestél a ló túlsó oldalára.

üdv,
Balázs
11

ha nincs js

lacy · 2009. Aug. 18. (K), 08.30
gex: Ha nincs js, akkor valóban nincs regisztráció, mindamellett reklámokat se fog látni, illetve a fórumban se fogja tudni használni azokat a dolgokat mint mások. Legyen bekapcsolt JS-e és nem csak az én oldalam miatt. Mindamellett ha nincs, akkor erről figyelmeztetem és megjelenik egy link egy cikkhez, ami megmutatja, hogy lehet ezt a különböző böngészők alatt bekapcsolni.

solkprog: Nem tudok róla, hogy a szerverhez fordulna jelszókitöltéskor, csak minden leütés megnézi a hosszát... a jelszóismétlő meg az egyezést.
12

"Jelszó újra"-ra gondoltam.

solkprog · 2009. Aug. 18. (K), 08.45
Amikor először írjuk be a jelszót akkor valóban nincs. De a "jelszó újra"-nál ahogy nézem már van AJAX.

üdv,
Balázs
14

nem ott!

lacy · 2009. Aug. 18. (K), 09.13
ott semmi ajax nincs, a biztonsági kód ellenőrzőben van, mert elküldi php-nek a karaktereket és az visszaválaszolja, hogy tetszik-e neki. az egészet jquery-vel kellett volna megoldani, ám akkor még nem volt olyan népszerű vagy csak én nem tudtam róla...
15

lényegében totál mindegy

solkprog · 2009. Aug. 18. (K), 09.22
Nem a kódot néztem csak azt hogy mikor mennek a kérések a szerver felé. De lényegében teljesen mindegy mikor de mennek. Egy jelszó ellenőrizéskor minek a szerver felé fordulni egyáltalán?
Egyébként a "biztonsági kód ellenőrzőében" mit értesz a "jelszó erősségi csikót"?

üdv,
Balázs
16

captcha

lacy · 2009. Aug. 18. (K), 09.36
a jelszó és jelszóismétlő beírásánál nem kellene ajax kérésnek lennie. amikor a captcha leolvasod és begépeled, akkor a begépelt cuccost elküldi phpnek a js és válaszból kiderül, hogy jó kódot írt-e be. a csíkot nem én írtam, elvileg figyeli a karaktereket, jeleket, de ahogy én észrevettem inkább a jelszó hosszával zöldíthető ki.
17

fejezzük be...

solkprog · 2009. Aug. 18. (K), 10.09
...mert ez (már) nem vezet sehová.
üdv,
Balázs
27

Re:

site · 2010. Szep. 6. (H), 00.17
9

lehet ezt jól is csinálni

erenon · 2009. Aug. 17. (H), 20.55
Lehet ezt takarékosan is csinálni. Minden leütés után várni kell 1-3 másodpercet, és csak akkor küldeni kérést, ha nem történik újabb esemény. Valamint lehet használni az onblur eseményt is.
13

igaz

lacy · 2009. Aug. 18. (K), 09.03
igazad van, valószínűleg ha egyszer váltok akkor onblurra fogok, bár ez önmagában kevés. kitölti az formot, majd utána akar foglalkozni a hibákkal, ezért visszakattint a rossz sorba. kijavítja. amíg nem lép ki a mezőjéből, addig nem hívódik meg az esemény, ami checkolná a sort, ő pedig nyilván nem fogja tudni, hogy most át kellene kattintani a következő jó sorba, hogy az előző validáljon.:D ez az egyik szépséghiba, a másik pedig az, hogy az utolsó mező kitöltése után nem fog kilépni a mezőből, hanem rögtön a regisztrál gombra akar majd kattintani, ami NÁLAM inaktív lesz, míg minden jól ki nincs töltve. többek között ezért is hajszoltam magam az onkeyup-ba, mert ez elég fix hogy lefut ha gépel a csávesz, de sajnos ennek is van két bibije (biztos tudjátok de leírom), mégpedig kettő:

1. kitöltesz egy mező és nyomsz egy tabot, akkor a tab lenyomására átugrik a következő mezőbe a kurzor, a tab felengedésekor pedig meghívódik a második mező onkeyup eseménye.:)) ez annyira gáz, de logikus.

2. azt vettem észre, hogy ha nagyon gyorsan gépelek akkor kikimarad vagy összecserélődnek a hívások, vagy nem megy el a szerverhez, ezt még nem tudom, de az új regformomnál ezért felhagytam az onkeyuppal, mert ha gyorsan gépeltem be az email címem és figyeltem a szerver válaszát akkor az email cím utolsó karakterének begépelése után az már nem jutott el a szerverig és vissza. nem tudom hol akadt el, de ott volt, hogy info KUKAC lacy.hu és a szerver utolsó válasza az volt, hogy az info KUKAC lacy.h egy nem valós email cím. így ez megbízhatatlan.:(
18

onkeyup, settimeout

gex · 2009. Aug. 18. (K), 12.44
1. megvizsgálod a karakter kódját.
2. onkeyup-ra nem küldesz egyből ajax kérést hanem csak időzítesz egyet 1-2 mp-cel későbbre. ha van új onkeyup ez alatt az 1-2 mp alatt, törlöd az időzítést és beállítasz egy újat.

erőforrásokról szépen elterelted a témát. ha kattingatok a név és emailcím mezők között akkor miért indulnak újra és újra ajax kérések?
10

mentett jelszavak?

eashlon · 2009. Aug. 17. (H), 23.29
másodikat azonban üresen hagyja, aminek egyenes következménye lesz, hogy ameddig ki nem tölti a felhasználó, addig nem tudja menteni beállításait. Szó mi szó, biztonsági intézkedésként nem utolsó


ezt nem értem pontosan, lehet nálam a hiba. Pl FF ha megjegyzi a jelszót akkor azt ugye alapból kb 3 kattintással elő lehet szedni. Nemnagyon hallottam volna bárkit is aki használná ugye az ez ellen kitalált "mesterjelszót". Akkor hol itt a "nem utolsó" biztonsági intézkedés?
19

Live search

kow · 2009. Aug. 25. (K), 21.01
Nem régen volt szükségem pont erre, amikor live search-öt írtam, 1 perc guglizás után jött is a kívánt eredmény.
20

Mi alapján egészíti ki a mezőket a böngésző?

phr3ak · 2009. Okt. 4. (V), 04.37
Gyakran tapasztalom, hogy újonnan megtekintett oldalakon is beír felhasználónevet és jelszót. Lehetséges, hogy ahogy ez kitöltődik "véletlen", egy js elpostolja a felhasználó tudta nélkül?
21

böngésző

Drawain · 2009. Okt. 4. (V), 13.44
Nem, a böngésző jegyzi meg a felhasználónév, email mezőkbe írt dolgokat, és más oldalon is felkínálja, hátha ugyanaz ott is.
22

Ezzel most nem tagadtad

Joó Ádám · 2009. Okt. 6. (K), 01.03
Nemmel kezded a mondatod, de amit írsz, az nem zárja ki, amit felvetettek.
23

kérdésére

Drawain · 2009. Okt. 6. (K), 13.20
Elnézést ha félreérthető volt, a "nem" a kérdésére volt válasz. Vagyis semmilyen JS nem játszik ebben közre, csupán a böngésző magánakciójáról van szó.
24

de

gex · 2009. Okt. 6. (K), 14.10
Lehetséges, hogy ahogy ez kitöltődik "véletlen", egy js elpostolja a felhasználó tudta nélkül?
szerintem meg de, elképzelhető.
25

akkor nem értem

Drawain · 2009. Okt. 6. (K), 14.43
Akkor nem értem miről beszélünk... Tehát először nézel meg egy új oldalt, amit még sohasem láttál, tehát ennek nincs is adata rólad. Az oldalon pedig fut egy js ami kinézi a neved/jelszavad valahogyan a többi oldalról és kitölti vele a felhasználónév-jelszó mezőt? Ez valahogy elég elképzelhetetlen számomra, azért elég jól el vannak szeparálva a különböző oldalak JavaScript környezetei...

Szerk: valószínű félreértettem a kérdést, az ugyanis nem arra vonatkozott, hogy mi tölti ki ezeket a mezőket, hanem arra, hogyha a böngésző kitöltötte, akkor elpostolhatja e (nyílván nem etikus szándékkal) az oldal. Ez így valóban megtörténhet. Elnézést mindenkitől, hogy félrevezettem a témát, mindenki lehet fáradt :)
26

csak meglett

gex · 2009. Okt. 6. (K), 14.46
a lényeg hogy meglett a végére. ;)

azt viszont én se nagyon értem hogy a böngésző egy teljesen idegen oldalnál miért és mivel tölti ki a név/jelszó párost. a keresőmezőnél néha nekem is felajánl ezt-azt a firefox de jelszónál sose próbálta.