GNOME Bugzilla – Bug 332951
hex wep key entry allows non-hex characters
Last modified: 2008-01-24 04:47:05 UTC
Upstreaming from: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181755 We can probably do this with a signal handler. ------------ Description of problem: When attempting to a wep protected wireless network, the NM authentication dialog is presented for entry of the hex wep keys / ascii wep keys / wep passphrase. When you select hex wep keys, the entry field for the key will accept non-hex values. I can see this being a reasonable behavior if switching between hex/ascii/passphrase saved the value in the field, but this is not the case. Version-Release number of selected component (if applicable): NetworkManager-0.5.1-12.cvs20060213 How reproducible: Always Steps to Reproduce: 1. Attempt to connect to wep network using NM 2. Wait for authentication dialog, choose hex wep key 3. Enter non-hex values Actual Results: Non-hex values were accepted as valid input for a hex only field. Expected Results: Field should have been filtered to 0-F.
But then an issue of course becomes, what happens when someone fills in a passphrase, wants to select ASCII key, but accidentally selects hex key... Do we clear the textbox? We'd almost have to... Would be nice for the already typed info to stick around if they go back to passphrase, though.
I am no GUI designer. But here are my thoughts. As you fill in a key and the select a different key type, the box is cleared. This is the current behavior. As Christopher Aillon points out in comment #1, this is sub-optimal from a usability point of view. However, I think if you ended up keeping a value per key type, so that if you re-selected that type, the value would re-appear, would be confusing for end users. Perhaps the correct behavior is that one value should be maintained and always displayed no matter what key type is selected. Then, if the key was invalid for that key type (ie. non-hex characters entered for hex key type), the confirmation button could be disabled and a message displayed that the key contains invalid characters. The confirmation button is already disabled when the key length is wrong in this situation, so it should be pretty easy to tie into that logic (easy to say without looking at the code).
Might that further confuse users? -- "Why is my confirmation button disabled? I typed in all the info!" Is that a good thing? Probably...
I think it would only make sense with a companion message something like "your key contains illegal characters" or "your key contains characters other than 0-9, A-F". Otherwise, you are correct, it would probably be very confusing.
*** Bug 341011 has been marked as a duplicate of this bug. ***
input is clamped now in trunk and stable; if/when we fix the password-clears-on-WEP-type-change we shouldn't blow away the entry but still filter it.