134103 - nsHttpChannel doesn't permit implementing non-interactive nsHttpAuthenticators

Status: RESOLVED FIXED

(Core :: Networking: HTTP, defect)

Description

[Elliot Lee]

Some authentication methods, such as Kerberos, do not require any user
interaction in order to respond to an authentication challenge. It should
therefore be possible for an authentication method to review the challenge and
available user/pass information prior to any user interaction.

To support a complete suite of authentication methods, mozilla should probably
adopt a model more like PAM, where components supporting various authentication
methods are handed the existing auth information and are then able as needed to
ask the application to retrieve particular auth information. It might make sense
to push the user interface down into the individual authenticator implementations.

Example use cases:
  basic auth (need a username/password, can be cached)
  digest auth (need a username/password, can't be cached due to sequence numbers)
  Kerberos (don't need any information besides the challenge, except
occasionally an external program should be run to renew an expired ticket)
  s/key (multi-step - need a username, then provide challenge number and token
to user, then need one-time-password)
  biometric (prompt user to provide a sample, external input determines when
dialog is done)

Comment 1

[Darin Fisher]

post 1.0 for sure, but shouldn't be too much work...

some things would have to change, since nsHttpChannel currently assumes auth is
username:password based.  it stores the last username:password to determine how
to handle a 401.  that should be trivial to modify.

-> mozilla 1.1alpha

Comment 2

[Don Smith]

Would it be possible with this to make basic auth not wait for a 401 but 
insstead simply just tack on the headers if prompted to? Is this proper 
behavior? I've seen several xmlrpc clients (java,..etc) which do this and I'm 
unclear whether this is the correct behavior or not, if not, does the fact that 
its' common make it a reasonable feature to implement

\

Comment 3

[Darin Fisher]

don: basic auth credentials are automatically forwarded when available and when
within the same authentication domain as determined per RFC 2617.  this bug is
about authenticators that don't require username:password to get the job done --
something we never considered when writing the HTTP authentication code.

Comment 4

[Darin Fisher]

mass futuring of untargeted bugs

Comment 5

[Yves Lambert]

http://www.viewline.net/ 
Mozilla doesn't acknowledge login information request by the ASP and this
generate a 401.2 error instead of 401.1
-> i submit a new bug 189170. mark it as DUPEME. mark it as blocking bug 12578
and bug 57529 and this sorry for the spam

Comment 6

[Christopher Nebergall]

This was fixed a long time ago with negotiateauth.