We were able to reproduce a problem while loging in to a password
protected webdav account/folder. The login-dialog appears again, but
then, after filling in the data again, everything works fine. It
seems, that there is a problem with the authentification of the
server. The string in the URL must content the whole adress !

Thanks for looking into this.

In my case, I entered the username/password many times and the dialog
still kept coming up.

Could you explain better why the response I suggested is incorrect? 
The URI that is hashed is supposed to be the value provided, which is
/content/Private/a.doc.  If OpenOffice is hashing the full URL, then
it should provide the full URL in the Authorization header.

By the way, maybe the reason it worked for you was that the WebDAV
server was requesting Basic authentication instead of Digest
authentication.  Basic authentication would not be affected by this bug.

As talked to the development section, digest authentication normally 
shouldn`t cause problems, but they`ll check the data above and will 
soon write a statement here.

Hi David,

The developer responsible for the WebDAV Content Provider (which is part
of the UCB project) and myself did have a look at both the source code
(which makes use of the 'neon' library, see http://www.webdav.org/neon)
and the communication with an Apache server (Apache/1.3.12 DAV/1.0.2).

The 'neon' source code seems to contain no deviation from RFC 2617. And
our experiments with an Apache server also did work okay (apart from
the smaller glitch mentioned by Thorsten).

Given our findings above, what server (make and version) are you using?
And how did you calculate your example H(A1) and H(A2) values?

Thanks,
Matthias

The H() function is just an MD5 hash.

You have to be really careful when looking at this kind of code.  If
one byte too many gets hashed (a space or a \n maybe?) then the whole
hash is off.  I had these kinds of problems when writing a program to
calculate the response, myself.

The server I'm using is an internal WebDAV server in development at my
company.  Obviously, the first thought that came to my mind was that
the server was at fault.  However, after looking at the packet traces,
I verified (as above) that OO is returning the wrong response code.

Here is a simple perl program to calculate the hashes I mentioned above:
-------------

#!/usr/bin/perl

use Digest::MD5  qw(md5 md5_hex md5_base64);

$ha1 = md5_hex("username:Authorized_Users:password");
print "h(a1) is $ha1\n";

$ha2 = md5_hex("GET:/content/Private/a.doc");
print "h(a2) is $ha2\n";

$result =
md5_hex("f18f399c54be1514486635599d10f441:4f5f7e31f1f7401f38b367900a97f292:00000001:TW9uLCAxMyBNYXkgMjAwMiAyMjo1NTo0MyBHTVQ=:auth:f764d020cd5e9d6871afd097579944ff");

print "result is $result\n";

----------------

I have run the same kind of program on Digest responses from IE, and
those responses have the correct response code, according to my perl
script.

By the way, which version of neon ships with OO 1.0?  I was lost
looking through the OO source code to try to find this bug, but maybe
I'll be able to figure something out in the neon code.

Sorry, one more thing... Are you sure your Apache server is requesting
Digest authentication?  By default, Apache will only use Basic.  You
need to use and configure mod_digest for it to use Digest authentication.

Thanks again,
david

More info...

I wrote a small client using neon-0.20.0, and it had no problem 
accessing our server with digest authentication.  But OO 1.0 still 
doesn't work.

According to the changelogs, some versions of neon had problems with 
digest authentication.  Maybe this is one of those bugs?

Thanks,
david

OO 1.0 uses neon 0.14.0 with one or two patches (pretty old but we had
no problems so far). If I got things right from the version history
there were only two issues re digest authentication between 0.14.0 and
0.20.0, both were fixed in 0.15.0 and yes, they are part of the
patches we apply to 0.14.0 used for OO.

Yes, our Apache is configured to use digest authentication for some
test resources, basic authentication for some others and no
authentication for the rest...

Does your test client work with neon 0.14.0? Does it with 0.15.0?

I had to modify my client a little bit because of the API changes in 
neon between 0.20.0 and 0.15.0, and between 0.15.0 and 0.14.0.  But 
after these modifications, I was able to access everything just 
fine.  So neon 0.20.0, 0.15.0, and 0.14.0 all work.  But OO 1.0 still 
doesn't work.  Maybe I should try 0.14.0 with the OO patch?

One thing that I should mention is that I'm running OO on Windows, 
but I'm writing my neon test client on Linux.  (Both intel systems) I 
don't think there should be a difference, but who knows.

Ummm... so I'm leaving for Hawaii tomorrow, so I won't be updating 
this bug from then until Monday next week.  :)

In case you're wondering about my test client, it just creates a 
session, sets the server_auth callback, then does an ne_get/http_get.
The password callback just does a gets for username and a gets for 
password.

Thanks,
david

Hmm, I'm looking at md5.c.pat, and I'm wondering if this could be the 
trouble:
  !       md5_uint32 WORD_ = words[0] | (words[1] << 8) \
  ! 	                   | (words[2] << 16) | (words[3] << 24); \

words is a const char *, not an unsigned const char *.  So if 
words[0] is negative, then it will be sign extended, which causes all 
of the top 3 bytes of WORD_ to be 0xff.  If you cast each element of 
words to unsigned char in the expression above, maybe this will fix 
the problem?

But I don't really know anything about md5.  And this doesn't explain 
why digest authentication seems to work for you.

Yeah, I think that's what it is.  I applied md5.pat.c (manually) to 
neon-0.14.0, and my test client stopped working.  When I added in 
four casts to unsigned char and recompiled, it started working again.

Your last comments gave me the final hint. Thanks! Seems that we have
a build problem!

Formerly neon recided in project 'util', module 'external',
subdirectory 'neon'. You're absolutely right, the patches there are
definitely broken. Months ago neon sources moved to project
'external', module 'neon'. With the new module everything should be
fine. Take a look into neon.patch - the casts you're missing in the
old patch file are there!

The new neon sources should have been used for OO 1.0, but obviously
this is not the case. I will hand over this bug to release engineering.

I just upgraded to ooo1.0.1, but this problem still exists.  Will the
correct patches be applied for ooo1.0.2?

removed ooo1.0 keyword in favour of target milestone "OOo 1.0.2".

please verify in rc.

closed.