Re: Feature request : make optional the UTF-8 encoding of user name and password during authentication

On 08.10.2010 17:00, Cedric Quilliot wrote:
> Hello,
>
> After a discussion in CollabNet forum
> (http://subversion.open.collab.net/ds/viewMessage.do?dsForumId=3&dsMessageId=386510),
> I discovered that TortoiseSVN always UTF-8 encode the username and
> passwords during a basic authentication challenge (in module SVN,
> file SVNPrompt, function SVNPrompt::simpleprompt).
>
> In my opinion this is a mistake (at least in some cases), and should
> be configurable.

Nope, sorry. This is not a mistake and I definitely won't change that.

> My SVN server configuration is : - using the last version of a
> CollabNET server, running on Windows 2003 - repositories are accessed
> using "basic authentication" and password are valided against an LDAP
> server.
>
> To sum it up, the original issue is : users having non-ASCII
> characters in their password can't authenticate with TortoiseSVN, but
> can authenticate successfully when direct login to Apache with a web
> browser.
>
> After looking deeper at the network frames, username and password are
> sent in the same code page as the user interface (Latin1 in my case),
> and password validation works fine.

And that only works because your server and client OS both use the same
code page. But since that's a rare situation, you only got lucky.

> But since TortoiseSVN always encodes in UTF-8 the password, a
> password containing an english pound (£) is always rejected.
>
> It is probable that the UTF-8 encoding is good in some
> configurations, but in my case it doesn't work, this prevents users
> from having non-ASCII characters in their password.
>
> What do you think of this evolution ?

The real problem here is that RFC2617 doesn't even mention the
encoding/codepage the password has to use, so this depends on the server
implementation and the OS it runs on.
* Opera uses UTF8
* IE uses the systems default codepage (which is never utf8) and just
silently mangles all chars that don't fit into that codepage.
* Mozilla/Firefox uses only the lower byte of character codepoints,
which makes it use ISO-8859-1 and also mangling all chars that that
don't fit into that codepage. However Mozilla uses UTF8 when doing
XLHttpRequests.
* Safari and Chrome encode to ISO-8859-1 like Mozilla.

In your case, it's not even the codepage of your svn server but the
codepage your LDAP server.

You should configure your LDAP server to use utf8 as its codepage.

If you would use simple authentication with Apache, you could just save
the passwd file in utf8 format and it would work.

Stefan

-- 
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=2669331
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].