Re: feedback on AUTHINFO in qgnus-0.27

["Edward J. Sabol" <sabol@alderaan.gsfc.nasa.gov>]

Excerpts from mail: (17-Feb-98) Re: feedback on AUTHINFO in qgnus-0.27 by Steinar Bang
Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
Lars> The new approach is to only send authinfo when challenged.  If you
Lars> want to force sending authinfo for some servers, you should put the
Lars> authinfo function into the server-opened hook for those servers. 

Steinar Bang <sb@metis.no> writes:
SB> I prefer an approach where you always check ~/.autinforc (or
SB> whatever), for the server, and send authinfo whether challenged or
SB> not. 

SB> Ie. the following behaviour:
SB> 1. if authinfo entry for this server found, send it whether
SB>    challenged or not, prompt for username and password if missing 
SB> 2. if no authinfo entry found, and no challenge is issued don't send
SB>    authinfo 
SB> 3. If challenged look for authinfo for the server in the
SB>    ~/.authinforc, and prompt for missing username and password, the
SB>    way it presumably does

Lars> Why should 3) look into .authinforc when 1) already has established
Lars> that it doesn't exist there?

Lars> Anyways, the problem is to decide which servers to send authinfo to
Lars> automatically.  I say we add some token to .authinforc -- "force",
Lars> perhaps?  Or (to keep compatibility with .netrc), have the user name
Lars> be of a certain form?  "login force:larsi" to say to nntp that it
Lars> should always send authinfo for this server?  

No, please don't do that. It's completely unnecessary and deviates from the
intentions of the .netrc file format. Sematically overloading a syntax is
almost never the correct way of doing things. If I may, let me reorder and
rewrite Steinar's procedure of how to handle this:

1. If challenged by some server, look for authinfo for that server in the
   ~/.authinforc file.
   a. If there is no ~/.authinforc file or if there is but there isn't an
      entry for the current server in it, prompt for username and password
      and then send the authentication information to the server.
   b. If there is an entry for the current server in ~/.authinforc but it
      lacks a username and password, prompt the user to enter them
      and then send the authentication information to the server.
   c. If there is an entry for the current server in ~/.authinforc and a
      username is specified but it lacks the associated password, prompt the
      user for the password and then send the authentication information to
      the server.
2. If no challenge is issued by the server, look for authinfo for that server
   in the ~/.authinforc file anyway.
   a. If there is no entry in the ~/.authinforc file for the current server
      or if no ~/.authinforc file exists, don't send any authentication
      information to the server.
   b. If there is an entry in the ~/.authinforc file for the current server
      but it lacks a username and password, prompt the user to enter them
      and then send the authentication information to the server.
   c. If there is an entry for the current server in ~/.authinforc and a
      username is specified but it lacks the associated password, prompt the
      user for the password and then send the authentication information to
      the server.

It sounds more complicated than it really is. Basically, if there's an entry
for the server in ~/.authinforc, then send authinfo for that server whether
challenged or not.

By the way, this is almost exactly how FTP uses the username and password
information in the ~/.netrc file.

Later,
Ed