cURL / Mailing Lists / curl-library / Single Mail

curl-library

preserve password prompting?

From: Daniel Stenberg <daniel_at_haxx.se>
Date: Mon, 13 Oct 2003 14:37:43 +0200 (CEST)

Prompting For Passwords With libcurl?
=====================================

Today's libcurl prompts for passwords in some cases. I'm now considering to
remove this feature, due to these two reasons:

A) It is a bit dubious for a library to do prompting to begin with.

B) User names and passwords are set by applications on the "easy handle".
   When a URL is then requested, they (user+password) are stored as properties
   for the specific connections, as user names and passwords might change
   between requests.

   This calls for problems. For example, when doing some of the
   multi-request[*] authentication schemes:

   We then need to get a URL using the specified user name, and if libcurl
   does the password prompting it needs to ask for a password. The password is
   unique for this connection. To complete the operation, libcurl itself will
   perform a second or even a third request, and each request will need to
   know the password. The password cannot be set automaticly for the following
   requests, since that would break the whole concept of multiple connections
   within libcurl.

Effects of Removal
==================

Reason B above makes the command line tool curl to prompt for passwords
multiple times. Fixing this with the current logic is not easy nor nice. I
assume other applications that rely on the prompting will suffer from the same
problem.

I would instead prefer to move the password prompting code from libcurl to the
application code, which then would remove all these problems and it would make
the libcurl password code a bit clearer.

Of course, this would affect all applications of today that rely on this
feature of libcurl. So, I would *REALLY* like to know if there are people or
rather applications out there that rely on this and what you (authors of such
apps) think about this plan of mine.

Removing this feature would of course make CURLOPT_PASSWDFUNCTION and
CURLOPT_PASSWDDATA obsolete.

Applications that enter no password to force a prompt today, would be using an
empty password in the version that has the prompting removed.

Work-arounds Instead of Removal
===============================

On the behalf of curl, I can always just duplicate the code and make sure that
curl always provide a password when using libcurl and thus it would never
excersize the prompt code in the library. This way, I can fix the
duplicate-prompt problem for curl and still leave the prompt code in the
library, but I would prefer to make a nice clean cut.

[*] = Digest, NTLM, Negotiate etc all require more than one HTTP request to get
      sent in order to fulfill a "handshake".

-- 
 Daniel Stenberg -- curl: been grokking URLs since 1998
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
Received on 2003-10-13