On Thu, 12 Dec 2013, Daniel Stenberg wrote:

> > I'm not a fan of the latter as that would require the user to
> > perform the following in order to specify the authentication
> > type in the email protocols:
> >
> > user:password;options=auth=NTLM
>
> I agree that it isn't perfect, but then I also cannot think of a really
> good way to solve this. Perhaps we should just not solve it and
> move it into a separate option entirely.

The other thing I don't like about this or by choosing any other separator
for that matter is that, it would prevent having that separator ";options="
for example in the password as well :-/

> > I can't remember which user and password options allow URL
> > encoded colons at present, and I know this is something that
> > we talked about before, but could we consider adding support
> > for URL encoding these separator characters in the
> > CURLOPT_USERPWD?
>
> It's not possible. The colon is the separator for [user]:[password] so
> it makes it impossible to use a colon in user names with the -u option
> (but passwords can have them since only the first is used as a
> separator).

What I mean there is, and this is from totally from memory, I think proxy
user:pass for example allows a colon to be present in the user part if it is
URL encoded - whilst the host user:pass doesn't. If we were to allow the
host user:pass;options to contain a URL encoded colon and semi-colon then
doesn't that fix everything, as well as providing consistency with proxy
user:pass ;-) ?

> For libcurl we have separate individual options that can be used
> instead to avoid this, and for the command line client a user can
> provide the user name (and password) in the URL instead and in
> there they can be used URL encoded and it works fine. The options
> cannot be passed in inside URLs like that.

The options can be passed into the URL as well - that was the original work
I did in May by adding support as per RFC-2384 and RFC-3501 (as well as the
draft SMTP URL syntax spec) ;-)

For example:

pop3://user:pass;auth=NTLM_at_mail.example.com/1

After I did that work, and again if memory serves me correctly, you asked me
to add support for the options to host user:pass so the interface for the
two was the same.

> The only truly working way I can think of is to have separate options
> for all of them so that we avoid single-letter separators completely.

I think separate options is something that we should consider.

> But since the user+password are at least already working in one way since
> quite a long user+time back, I think we should start with unbreaking that
> to get back to the state we were in before...

That's something I really can't answer. If it was me, I would simple URL
decode the user, password and options when passed in via the -u option /
CURLOPT_USERPWD option after they have been split into their separate parts.
That way:

* The -u option would then be consistent with the user+pass+options when
passed into the URL
* The -u option would then be consistent -U (proxy user+pass)
* A colon in the username would then be allowable by encoding it as %3A -
thus fixing the long outstanding limitation of usernames
* A semi-colon in the password would then be allowable by encoding as %3B -
thus fixing the more recent limitation

For example:

-u auserwitha%3Abeforethe:passwordwhichalsocontainsa%3Bbeforethe;auth=NTLM

Would give a username of " auserwitha:beforethe" and a password of
"passwordwhichalsocontainsa;beforethe" with the options as "auth=NTLM" ;-)

Kind Regards

Steve
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2013-12-13