ietf-nntp Multiple AUTHINFOs per session
Jeffrey M. Vinocur
jeff at litech.org
Mon Jan 6 07:37:40 PST 2003
On Sun, 5 Jan 2003, Ade Lovett wrote:
> However, the fact that a new instantiation of the client is being suggested
> when a client re-authenticates is a blatantly obvious way of killing a
> server, unless serious amounts of state are saved on a reauth, which kinda
> defeats the purpose of the whole thing.
>
> It's more a case of a solution sounds ok, but then turns out to be
> inherently unscalable, causing everyone needless pain (the rift between
> server and client developers is big enough as it is :()
Whoops, I think we're miscommunicating.
As I understood Ken, he was saying that we should disallow multiple
AUTHINFOs because the *client* can start a new session (as you describe),
not that the server should be handling it internally as a fork().
Additionally, I certainly don't plan on *requiring* the server to support
multiple AUTHINFO; it is always going to be permissible for a server to
return 502 for anything it doesn't want to let the client do.
The question is whether the NNTP auth spec should *forbid* the client from
doing multiple AUTHINFO. I'm torn on this -- there's no tremendously
useful reason to want it, but on the other hand if an implementation can
provide it with no extra effort, there's nothing wrong with it.
How about a compromise? This draft specifies an AUTHINFO capability to be
returned by LIST EXTENSIONS. How about I point out that a server which
does not want clients to do multiple authentications steps can avoid
listing that capability after authentication has been performed?
> All IMO, of course, having written a couple of "industrial-strength"
> servers, and now managing a REAL one :)
So, you didn't answer my original survery -- what does your server do if
a client that has already authenticated sends AUTHINFO again?
--
Jeffrey M. Vinocur
jeff at litech.org
More information about the ietf-nntp
mailing list