Closed
Bug 138684
Opened 22 years ago
Closed 22 years ago
Account password entered in Java applet does not get through to the server
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: aoliva, Assigned: john)
References
()
Details
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc1) Gecko/20020417 BuildID: 2002041711 Below `Agencia' and `Conta', on the left of the web page, there's a Java applet in which you're supposed to enter your password. No matter what I enter there, after I click on the `entra' button, I get back the same web page, now with an error message in red below the applet, saying `Atenção: senha: conteúdo nulo' (meaning Attention: password: null contents). The same web page works fine on Netscape 4.79-1, on the same machine and OS. It fails similarly with Mozilla 0.9.9 included in Red Hat Linux skipjack-beta2, using Sun JRE 1.4.0 as the Java plug-in, and with Mozilla 0.9.9 on MS-Windows 2000. Reproducible: Always Steps to Reproduce: 1.browse to that web page 2.enter `1-9' for both `Agência' and `Conta' (otherwise the check-digit verification will fail before the password is tested) 3.enter anything at all as the `Senha de auto-atendimento' in the Java applet 4.click on `entra' Actual Results: An error message saying the password as blank is displayed: Atenção: Senha: Conteúdo nulo ! Expected Results: If an incorrect password, with 8 digits or longer, is entered, you should get to a web page saying `DADOS NAO CONFEREM'. If a non-blank password that is too short is entered, you'll remain in the same web page, with a message saying the password must have at least 8 characters: Atenção: Senha: Conteúdo deve ter no mínimo 8 caracteres ! If the correct password were entered, you'd gain access to the account, but you're not supposed to get that far :-) I'm notifying the bank that some people may be trying out odd passwords on that web page for account 1-9 1-9. Hopefully this won't be a problem :-) I'm not really sure this is a problem with LiveConnect, but I found some similar bug reports in this category, but they appear to affect Mac platoforms only, so I thought I'd report it anyway.
Comment 1•22 years ago
|
||
Confirming reported behavior with Mozilla trunk binary 20020415xx WinNT. OS: Linux ---> All. But I can't see any problem with the pure LiveConnect at the site. Here's how it's coded: <form action="/aapf/aai/login.pbk" method="POST" name="form" autocomplete="off" onSubmit="getSenha()"> ETC. ETC. <td> </td><td height="19" valign="bottom" class="loginTitulo"> <applet tabindex="4" code='br/com/bb/aapf/bbteclado/CampoTeclado.class' cabbase='/aapf/imagens/teclado/BBTeclado001.cab' archive='/aapf/imagens/teclado/BBTeclado001.jar' codebase='/aapf/imagens/teclado/' name='tclJava' id='tclJava' width='167' height='89' mayscript> <param name='local' value='login'> <param name='campoAnterior' value='numeroContratoOrigem'> <param name='campoPosterior' value='botaoOk'> <param name='colorLabel' value='0x000084'> <param name='colorField' value='0xFFFFFA'> <param name='colorBorder' value='0xBBBBBB'> <param name='colorBackground' value='0xF7F7F7'> Para sua segurança,<br> <a href="http://www.bancobrasil.com.br/appbb/portal/bb/ds/ajudaTecladoVirtual.jsp"> clique aqui</a> e habilite o seu teclado virtual até 24/04/2002<br> <font class='nomeInput11'>Senha de Auto-Atendimento</font><br> <input type="password" name="senhaConta" maxlength="8" size="10" tabindex="4"> </applet> <input type="hidden" name="senhaConta" value=""> <input type="hidden" name="botaoOk.x" value=""> </td> The onSubmit handler for the form, getSenha(), is coded as follows, from view-source:https://www2.bancobrasil.com.br/aapf/includes/formatadadosns2.js : function getSenha() { if ( document.applets['tclJava'] ) { var senha = document.applets['tclJava'].getSenha(); document.form.elements['senhaConta'].value = senha; } } Note the function tries to assign the value |senha| to the element document.form.elements['senhaConta'] This session from the Mozilla JavaScript Debugger shows that the pure LiveConnect is working properly. I entered '1234' in the 'Senha de auto-atendimento' input in the Java applet, hit the 'entra' button, and got the correct value |senha| coming out: FROM JS DEBUGGER: --------------------------------------------------------------------------- document.applets['tclJava'] [HTMLAppletElement] [class: HTMLAppletElement] {0} senha [JavaObject] [class: JavaObject] {0} senha.toString() [JavaObject] [class: JavaObject] {0} senha [JavaObject] [class: JavaObject] {0} senha.length() [integer] 4 senha.charAt(0) [integer] 49 senha.charAt(1) [integer] 50 senha.charAt(2) [integer] 51 senha.charAt(3) [integer] 52 senha + ''; [string] "1234" String(senha); [string] "1234" ---------------------------------------------------------------------------
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
Comment 2•22 years ago
|
||
Reassigning to DOM Level 0 for further analysis, but this could be an OJI issue; I can't tell - Idea: perhaps we're getting a conflict between the two <input> elements defined above. One is inside the applet, the other one is outside it, but they both have the same name, 'senhaConta': <input type="password" name="senhaConta" maxlength="8" size="10" tabindex="4"> <input type="hidden" name="senhaConta" value=""> So when the onSubmit handler for the form above, getSenha(), tries to assign the value |senha| to document.form.elements['senhaConta'] which of the two is |senha| getting sent to? That may be the problem here - FROM JS DEBUGGER: --------------------------------------------------------------------------- document.form.elements['senhaConta'].value [void] void document.form.elements['senhaConta'] [HTMLCollection] [class: HTMLCollection] {0} ---------------------------------------------------------------------------
Assignee: rogerl → jst
Component: Live Connect → DOM Level 0
QA Contact: pschwartau → desale
Comment 3•22 years ago
|
||
Another idea: perhaps Mozilla IS finding the correct <input> 'senhaConta' when trying to make the assignment document.form.elements['senhaConta'].value = senha But perhaps the DOM is failing to make the assignment from the JavaObject |senha|. It is of Java class java.lang.String, I believe, from this session in the Mozilla JS debugger: --------------------------------------------------------------------------- senha [JavaObject] [class: JavaObject] typeof senha [string] "object" senha.__proto__ [Object] [class: Object] var s = ''; for (p in senha) {s+= p + ' = ' + senha[p]}; print(s); Caught exception: InternalError: Java class java.lang.String has no public field or method named "nodeName" --------------------------------------------------------------------------- I'm wondering if the DOM is failing to extract the character data out of the JavaObject |senha|. The data is there, as we saw in Comment #1, but perhaps the DOM isn't extracting it successfully. Note that in my debugging from Comment #1, I did this to get the character data: --------------------------------------------------------------------------- senha + ''; [string] "1234" String(senha); [string] "1234" --------------------------------------------------------------------------- Meanwhile, trying to track down document.form.elements['senhaConta'], this is all I could think of to try : --------------------------------------------------------------------------- document.form.elements['senhaConta'].outerHTML; [void] void document.form.elements['senhaConta'].innerHTML; [void] void document.form.elements['senhaConta'].parent; [void] void document.form.elements['senhaConta'].__parent__; [Window] [class: Window] ---------------------------------------------------------------------------
Comment 4•22 years ago
|
||
Following jst's suggestion, I loaded the site in IE6 and Mozilla and used javascript:alert() to make these comparisons: IE6 MOZ document.getElementsByTagName('input').length 6 7 document.applets[0].getElementsByTagName('input').length 0 no alert! document.getElementsByName('senhaConta').length 1 2
Comment 6•22 years ago
|
||
*** Bug 144206 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 7•22 years ago
|
||
FWIW, I've just been surprised to find out that this works fine on AOL Netscape 6.2.2, on Red Hat Linux 7.3 (using Sun JRE 1.4; the JRE that ships with AOL Nescape crashes as the web page opens, even with LD_ASSUME_KERNEL=2.2.5). Any chance of having the fix merged into Mozilla 1.0?
Reporter | ||
Comment 8•22 years ago
|
||
Ok, so it was not a bug fix in Netscape 6 that fixed the problem, after all. Simply adding `Netscape6' to User-Agent was enough to get this web page going just fine with Mozilla 1.0rc2. /me grumbles about web site developers that don't care about Mozilla... Any chance of getting `Netscape6' added to the default user-agent compatibility list? Or perhaps of having some means to *add* information to the User-Agent, instead of completely overriding it? Anyway, here's what I have in prefs.js for now: user_pref("general.useragent.override", "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc2) Gecko/20020510 Netscape6");
Comment 9•22 years ago
|
||
Adding Brazilian evang expert who has been involved in this discussion with the site at hand.
Comment 10•22 years ago
|
||
*** Bug 159772 has been marked as a duplicate of this bug. ***
Comment 11•22 years ago
|
||
*** Bug 144616 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 12•22 years ago
|
||
Of course, just a few days after I found the work around, the web developers at the bank seem to have found a way to prevent me from using their web banking: the Java applet now freezes all of Mozilla when I use it. Eek. But I found a nice work-around: using the Mozilla user Agent Override side bar, http://mozilla-evangelism.bclary.com/sidebars, I add `Macintosh' to the user agent string and, voila, the web page that is presented doesn't require Java at all any longer.
Comment 13•22 years ago
|
||
Phil, you were correct on comment #2. I'm in contact with them and they removed the input type inside the applet tag, so the password is now going to the server. A weird behavior now is that when you move focus to the applet, the text cursor continues on the HTML text field. I created bug 162317 for this.
Comment 14•22 years ago
|
||
Below is is a copy of the Java errors (first line, "java.lang.NullPointerException" is visible in the gray area where the applet should have painted its window). Picked this with 1.0rc1 but it's the same with the latest builds. ------------------------------------- Java(TM) Plug-in: Version 1.4.0_01 Using JRE version 1.4.0_01-ea Java HotSpot(TM) Client VM User home directory = C:\Documents and Settings\PJ Proxy Configuration: Browser Proxy Configuration ---------------------------------------------------- c: clear console window f: finalize objects on finalization queue g: garbage collect h: display this help message l: dump classloader list m: print memory usage o: trigger logging p: reload proxy configuration q: hide console r: reload policy configuration s: dump system properties t: dump thread list x: clear classloader cache 0-5: set trace level to <n> ---------------------------------------------------- java.lang.NullPointerException at sun.net.www.protocol.http.AuthenticationInfo.getProxyAuth(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection.setPreemptiveProxyAuthentication(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection.sendCONNECTRequest(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection.doTunneling(Unknown Source) at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.setProxiedClient(DashoA6275) at sun.net.www.protocol.https.PluginDelegateHttpsURLConnection.superConnect(Unknown Source) at sun.net.www.protocol.https.PluginDelegateHttpsURLConnection.access$100(Unknown Source) at sun.net.www.protocol.https.PluginDelegateHttpsURLConnection$2.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at sun.net.www.protocol.https.PluginDelegateHttpsURLConnection.connect(Unknown Source) at sun.net.www.protocol.https.PluginDelegateHttpsURLConnection.getInputStream(Unknown Source) at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(DashoA6275) at sun.plugin.net.protocol.http.HttpUtils.followRedirects(Unknown Source) at sun.plugin.cache.CachedJarLoader.download(Unknown Source) at sun.plugin.cache.CachedJarLoader.load(Unknown Source) at sun.plugin.cache.JarCache.get(Unknown Source) at sun.plugin.net.protocol.jar.CachedJarURLConnection.connect(Unknown Source) at sun.plugin.net.protocol.jar.CachedJarURLConnection.getJarFile(Unknown Source) at sun.misc.URLClassPath$JarLoader.getJarFile(Unknown Source) at sun.misc.URLClassPath$JarLoader.<init>(Unknown Source) at sun.misc.URLClassPath$2.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at sun.misc.URLClassPath.getLoader(Unknown Source) at sun.misc.URLClassPath.getLoader(Unknown Source) at sun.misc.URLClassPath.getResource(Unknown Source) at java.net.URLClassLoader$1.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(Unknown Source) at sun.applet.AppletClassLoader.findClass(Unknown Source) at sun.plugin.security.PluginClassLoader.findClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) at sun.applet.AppletClassLoader.loadClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) at sun.applet.AppletClassLoader.loadCode(Unknown Source) at sun.applet.AppletPanel.createApplet(Unknown Source) at sun.plugin.AppletViewer.createApplet(Unknown Source) at sun.applet.AppletPanel.runLoader(Unknown Source) at sun.applet.AppletPanel.run(Unknown Source) at java.lang.Thread.run(Unknown Source)
Comment 15•22 years ago
|
||
I verified today that the applet now loads so the virtual keyboard and the password field are shown correctly. However, one is required to enter password by clicking on the virtual keyboard, because the cursor does not show up on the password field and keyboard keystrokes do not pass thru. Comment: the virtual keyboard was introduced as a security measure, to difficult scooping the keyboard buffer or else; however, it makes it exceedingly easy even for a non-criminal looking over the shoulder to follow the cursor movement and discover the password - it is much easier to cover the keyboard are with the body if one is in a public place.
Comment 16•22 years ago
|
||
Paulo, Additional comment #2 shows that there are 2 fields with the exact same name for the password, which appears to be confusing Mozilla when you hit TAB. About the security of clicking on buttons for the password, I already asked this to myself a lot :)
Comment 17•22 years ago
|
||
Oops! My last comment was not precise, sorry for that. I was mislead because the cursor doesn't appear on the screen; however, if one clicks over the password field and enters numbers, asterisks appear after each number entered so it is possible indeed to enter a complete password. Not entirely fixed because of the invisible cursor but functional.
Assignee | ||
Comment 18•22 years ago
|
||
Marking fixed from comments above. I don't see the invisible cursor problem either, but if that still exists, please file a new bug that references this one.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Comment 19•21 years ago
|
||
Unfortunately this bug is back. The site has changed and now I can't login. The work around (using Macintosh in the user agent) does not work either. Using: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 Java(TM) Plug-in1.4.1_02
Reporter | ||
Comment 20•21 years ago
|
||
WORKSFORME with stock Mozilla in Red Hat Linux 9 (mozilla-1.2.1-26), with j2re-1.4.1_01-fcs
Comment 21•21 years ago
|
||
Right... it works with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 Java(TM) Plug-in1.4.1_02 But you cannot use TAB to change focus from field "conta" to "senha de auto-atendimento". Actually, it changes focus from "conta" to "entrar" button. If you use TAB it won't work. You must leave focus in "conta" and enter the password. Then click "entrar". This way it works.
You need to log in
before you can comment on or make changes to this bug.
Description
•