On Tue, Jul 8, 2014 at 7:14 AM, Branko Čibej <br...@wandisco.com> wrote: >...
> I just realized that even the variant without --force and with access to > the may not always work. Consider what "authenticate" means in ra_serf: > it would rely on issuing a request to the server that does not modify > the repository, but does trigger the part of the HTTPd configuration > that causes the server to respond with an authentication request. There > is no way to tell how the server is configured and therefore which HTTP > methods to which URLs will require authentication. > Right. In general, you have to attempt a modification before a (typically-configured, HTTP-based) server will query for your credentials. That said, this is a command that is run specially. Maybe ever just once. It would be okay to make several requests to the server. In increasing difficulty, the client could issue 1-3 requests to try and trigger an authentication event: 0) client certificate needed to open TLS session 1) the opening OPTIONS request 2) HEAD or PROPFIND on a resource 3) POST/MKACTIVITY to begin a commit (then DELETE if successful) That would likely trigger auth in 99% of configurations. (I could envision a server with anon-write to most areas, and auth-write to specific paths, so a "real" commit with paths would be needed) Seems a new RA entrypoint would be appropriate, to build something like this. Cheers, -g
