"back out" of basic auth without displaying 401 error page

RESOLVED WONTFIX

Status

()

Core
Networking
P5
enhancement
RESOLVED WONTFIX
17 years ago
3 years ago

People

(Reporter: Mike Gebis, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

17 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:0.9.8+) Gecko/20020131
BuildID:    2002013122

This is really a feature request.

When I click on a link that (unknown to me) requires basic authentication, I'm
presented with a dialog asking me for a username and password.  At this point,
I'm thinking, "Ooops, I don't have a username and/or password, I can't get this
link."

I then click "Cancel", which brings me to a "401 Authorization Required" page
which tells me, "You don't have a username and/or password, you can't get this
link."  I already knew that.

What I'd like is a third button on the authorization dialog which is, "Forget I
ever clicked on this link, and don't bring me to a useless 401 page, just leave
me on the current page".

Of course, that seems hard to fit on a button, so I'm open to better names. :)



Reproducible: Always
Steps to Reproduce:
1.Click on any page using basic authentication

Comment 1

17 years ago
perhaps "OK" "Ignore" "Cancel" would be better.

  OK     = send username and password
  Ignore = don't send a username and password
  Cancel = send me back to the page from whence i came

at any rate, this is probably not going to make it within the moz 1.0 timeframe.

-> future
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Priority: -- → P5
Target Milestone: --- → Future
Why even have an Ignore button if all that does it take you to a 401 page?  IMO,
the behaviour should be

  OK     = send username and password
  Cancel = send me back to the page from whence i came

Comment 3

17 years ago
i thought about that, but it's possible that the 401 page could have information
for a user that doesn't remember their password, for example.  in other words, a
website could expect the user to see the 401 page for whatever reason.

Comment 4

16 years ago
*** Bug 146494 has been marked as a duplicate of this bug. ***
As the admin of a site where the 401 page is a form that the user can fill out
to get a new password, we should show the 401 page... ;)
Whatever the number and labels of buttons, "Cancel" should cancel, not go
forward, anywhere. >:|

Comment 7

16 years ago
It's *not* going "forward", though.  It's already loaded the 401 page along with
all of its content.  It's just delaying the display of this content pending your
response to the authentication dialog.  If you click Cancel, it shrugs and
displays what it has.  If you click OK, it discards the 401 response's content
and tries again with the authentication credentials you provided.

So really, it *is* cancelling.  It's cancelling the retry-with-authentication
request that it's about to try and do.

I almost prefer the three-button option, but I can't think of some good sensical
labels that would make that arrangement sensical to the casual user.  Lacking
that, the current behavior makes the most sense (especially where the 401
content is valuable).

Comment 8

16 years ago
*** Bug 190919 has been marked as a duplicate of this bug. ***

Comment 9

16 years ago
to comment #5: This use is somewhat misleading, since a user wants
to see that form only if he really forgot his password, which he
usually recognizes after clicking submit, not cancel. A user clicking
cancel really does not want to see any action afterwards (except a
disappearing password dialog...).
Or in a another view, what's the difference between the buttons now ?
Functionally, nearly nothing.
So I would vote to really implement what a user expects from the
buttons, regardless of what's happening behind the curtains.
If you prefer the three button solution, it's ok from my view.
> Or in a another view, what's the difference between the buttons now ?

If you click "OK" with the wrong password you get the same dialog back again as
the site responds with a 401. This is the only acceptable course of action on "OK".

Given that, if the user is to ever see the error page another button needs to be
clicked.  Currently, that would be "cancel".

Comment 11

15 years ago
If we are going to muck with this, all buttons have to make more sense. Maybe:

[send|login] [quit] [back] ?

I don't think we can change the individual meanings of the current buttons, that
would break compatability. I don't think we should just add one more button,
because the real problem is the current buttons don't make enough sense.
QA Contact: tever → httpqa
Summary: Ability to "back out" of basic auth → "back out" of basic auth without displaying 401 error page

Comment 12

15 years ago
Looks good, esp. 'back' is a very clear description of the intended action.

Comment 13

15 years ago
I might advise against the use of "Login" for the button's label.  To "log in"
implies the creation of a session, when that isn't necessarily the case.  The
user is simply authenticating for this specific request.  Subsequent requests
may not require authentication, nor is there always a session the user must "log
out" of.

Perhaps:

   [ OK ]  [ Ignore ]  [ Abort ]

Or:

   [ OK ]  [ Do Not Authenticate ]  [ Cancel ]

The first attempts to authenticate, the second dismisses the dialog and displays
the 401 response, and the third aborts the "logical" request entirely, reverting
to the page the user just visited.

I wouldn't worry too much about the labels of the buttons breaking
"compatibility".  It's just UI.  If someone hits Cancel expecting the old Cancel
behavior, no harm is done.  They can repeat the request and pay more attention
this time without breaking anything.

Comment 14

12 years ago
-> default owner
Assignee: darin → nobody
Status: ASSIGNED → NEW
Component: Networking: HTTP → Networking
QA Contact: networking.http → networking
Target Milestone: Future → ---
showing the 401, with information, is the right thing.. and http auth is pretty infrequently used these days anyhow
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.