From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/14180 Path: main.gmane.org!not-for-mail From: "Edward J. Sabol" Newsgroups: gmane.emacs.gnus.general Subject: Re: feedback on AUTHINFO in qgnus-0.27 Date: Thu, 19 Feb 1998 10:55:16 -0500 Sender: owner-ding@hpc.uh.edu Message-ID: <199802191555.KAA18753@alderaan.gsfc.nasa.gov> References: NNTP-Posting-Host: coloc-standby.netfonds.no X-Trace: main.gmane.org 1035153415 13409 80.91.224.250 (20 Oct 2002 22:36:55 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 22:36:55 +0000 (UTC) Return-Path: Original-Received: from xemacs.org (xemacs.cs.uiuc.edu [128.174.252.16]) by altair.xemacs.org (8.8.8/8.8.8) with ESMTP id JAA25012 for ; Thu, 19 Feb 1998 09:58:32 -0800 Original-Received: from gizmo.hpc.uh.edu (gizmo.hpc.uh.edu [129.7.102.31]) by xemacs.org (8.8.5/8.8.5) with ESMTP id LAA22233 for ; Thu, 19 Feb 1998 11:56:45 -0600 (CST) Original-Received: from sina.hpc.uh.edu (sina.hpc.uh.edu [129.7.3.5]) by gizmo.hpc.uh.edu (8.7.6/8.7.3) with ESMTP id KAN13592; Thu, 19 Feb 1998 10:33:19 -0600 Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Thu, 19 Feb 1998 09:56:15 -0600 (CST) Original-Received: from claymore.vcinet.com (claymore.vcinet.com [208.205.12.23]) by sina.hpc.uh.edu (8.7.3/8.7.3) with SMTP id JAA13240 for ; Thu, 19 Feb 1998 09:56:08 -0600 (CST) Original-Received: (qmail 15333 invoked by uid 504); 19 Feb 1998 15:55:17 -0000 Original-Received: (qmail 15330 invoked from network); 19 Feb 1998 15:55:17 -0000 Original-Received: from alderaan.gsfc.nasa.gov (128.183.127.237) by claymore.vcinet.com with SMTP; 19 Feb 1998 15:55:17 -0000 Original-Received: by alderaan.gsfc.nasa.gov (950413.SGI.8.6.12/951211.SGI.AUTO) id KAA18753; Thu, 19 Feb 1998 10:55:16 -0500 Original-To: Gnus Mailing List In-reply-to: (message from Steinar Bang on 17 Feb 1998 09:49:19 +0100) Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:14180 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:14180 Excerpts from mail: (17-Feb-98) Re: feedback on AUTHINFO in qgnus-0.27 by Steinar Bang Lars Magne Ingebrigtsen 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 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