Closed Bug 11247 Opened 25 years ago Closed 25 years ago

QuickFill RFE for the first "Incorrect Key" dialogue?

Categories

(Toolkit :: Form Manager, defect, P3)

x86
Windows 95
defect

Tracking

()

VERIFIED WONTFIX

People

(Reporter: kevinyen, Assigned: morse)

Details

Steve,
Do you think it'd be a good idea to update the first "Incorrect Key" dialogue,
so that the user can re-enter a key right in that dialogue box?

This would minimize the times dialogues pop-up and save the user a logical key
stroke.  So the box might look like:

The QuickFill key you entered is incorrect.  Please re-enter your key if you
want to try again:
                       __________________________

		            [Cancel]	[OK]

-------------
We can fine-tune the wording, but I think the idea would improve the UE.

Also, speaking of UE, I'm communicating UE ideas as quickly as I can.  I wish I
had begun to do so sooner, though, to make it easier on you.  Unfortunately,
client UE team kept on saying that they would get to it (saying this for about 3
months now).  I finally realized that they won't.  In any case, I'm doing what I
can now.

thx,
kevin
If we did this idea, we'd have to work out the "lockout" threshold.  Is it
best to lockout quickfill:
1. even if the user cancels out of this screen?
2. only if the user enters an incorrect entry on this screen?
3. if there are two, cumulative incorrect entries in any one browser session?

I'm think the third is the best.  What are your thoughts?
Status: NEW → ASSIGNED
Why don't we make it really easier for the user and give him the following box
when he enters an incorrect password:

   The key you entered is incorrect.  Try using "..." instead.

Seriously, though, I like Kevin's suggestion.  I'll make this change
immediately.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → WONTFIX
On second thought, I'm starting to think this is a bad idea.  Although I was
being sarcastic with my example, we are making it easy for someone to hack in.
All sites that I can think of go to a failure screen and force the user to
return back to the login screen for a future attempt.

Besides the anti-hacking protection that this inconvenience provides, it also
makes it clearer to the user as to what is happening.  If I attempt a login and
fail, I get back to a screen that is again asking for a login and I might not
even notice that it is different from the original login screen.  So I'd think
that the system is rejecting logins.

For these reasons I'm closing this out.
Good points on the hacking protection.  The normal, appropriate user will not
see this screen at all most of the time.  And it's ok to make a nuisance for the
 hackers or tamperers.

Not quite sure what is meant in your second paragraph, but you hacker-targetting
is sufficient in itself for making this "WONTFIX"
Status: RESOLVED → VERIFIED
Product: Core → Toolkit
QA Contact: paulmac → form.manager
You need to log in before you can comment on or make changes to this bug.