Could not authenticate to server (svn authentication)

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Using the Bugzilla plugin with Subversion running in Apache httpd

2. Running hook.pl with all required parameters, with the 4 params in a 
configuration file.

3. Both Bugzilla and Subversion are hosted in the same Apache installation

What is the expected output? What do you see instead?
After a fair amount of trial and error have got down to an authentication 
error. I expected to have a successful VCS.add_commit at this point, but am 
getting this error which appears to be the Bugzilla service unable to 
authenticate in Subversion:

-bash-3.2$ perl hook.pl --config=hook.conf --project=core/trunk/ --revision=1 
--bug=1

Bugzilla Error: (32000) An error occurred while attempting to fetch commit 1 
from the "core/trunk" project in the "http://my_host/repos/svn/myrepo/" 
repository. Sometimes this means that you specified an invalid repository or 
project. The error was: Authorization failed: OPTIONS of 
'http://my_host/repos/svn/myrepo': authorization failed: Could not authenticate 
to server: rejected Basic challenge (http://my_host) at 
lib/VCI/VCS/Svn/Repository.pm line 12

I have tried testing with svn ls URL which works okay for my own userid. I 
suspected that since Apache httpd was running under userid _www that I might 
need to add that userid to svn auth file as well, but this still gives same 
result.

Is there a simple way to troubleshoot authentication into svn from the service, 
other than running the whole stack? Perhaps more detailed diagnostic?

When I go to the code referenced above I see this, but not sure how to 
interpret what's going there:

has 'x_ra' => (is => 'ro', isa => 'SVN::Ra', lazy => 1,
               default => sub { SVN::Ra->new(url => shift->x_root_noslash) });

What version of the product are you using? On what operating system?
Using VCS-0.2. Running on Mac OS X Snow Leopoard

Please provide any additional information below.

Any insights would be appreciated. I was also wondering if there is a way to 
simply supply the svn username:password via parameter or configuration to 
verify whether this is the actual problem.

Original issue reported on code.google.com by pat.pode...@gmail.com on 24 Apr 2011 at 4:45

[GoogleCodeExporter]

I forgot to mention that sync does work as long as I run on the svn server and 
specify the path. The commits are successfully added to the Bugzilla bug in 
this case. However sync gives the same error as mentioned earlier when 
specifying the server URL.

This works:
perl sync.pl --type=Svn -as=username@foo.com  --verbose 
file:///opt/repos/svn/myrepo/

This gives same authentication error as mentioned earlier:
perl sync.pl --type=Svn -as=username@foo.com  --verbose 
http://my_host/repos/svn/myrepo

Original comment by pat.pode...@gmail.com on 24 Apr 2011 at 5:25

[GoogleCodeExporter]

I don't see how the Subversion credentials ever get passed into the Bugzilla 
VCS.add_commit service so that it can use them when connecting to Subversion.

In lib/VCI/VCS/Svn.pm, the SVN::Client gets created with empty config hash:

sub _build_x_client {
    my $self = shift;
    return SVN::Client->new(config => {});
}

When running the hook.pl script, I can see the access to the Subversion 
repository in the access log file. There is an OPTIONS call that returns http 
code = 401 which fails the hook.pl invocation.

The credentials for the Subversion user reside in the directory:

   $HOME/.subversion//auth/svn.simple

and I can verify that the respective user can access Subversion using the 
standard svn command line client with these credentials. I just don't see where 
the SVN::Client ever gets the credentials.

How can I help Bugzilla to use the correct Subversion credentials so that it 
won't fail?

Original comment by pat.pode...@gmail.com on 5 May 2011 at 7:30

[GoogleCodeExporter]

Hey! The authentication feature is actually missing in the underlying VCI 
library from CPAN. However, I'm also the maintainer of that library, so you're 
welcome to send me a patch to it.

Original comment by avatrax...@gmail.com on 6 May 2011 at 6:29

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Original comment by pat.pode...@gmail.com on 11 May 2011 at 6:13

[GoogleCodeExporter]

Well after some digging, I located two places where svn authentication was 
involved in the VCI library. I was able to get sync.pl and hook.pl working with 
svn auth.

The 2 modified files were:

--  lib/VCI/VCS/Svn/Repository.pm
--  lib/VCI/VCS/Svn.pm

Note that these are just hacks at this point to put the svn auth into place. 
Credentials could be read in from a file (or maybe the .subversion auth data?) 
- this was just to test out where the auth was needed in the VCI code.

I added an auth hash to the client new like so:

For example in Svn.pm, _build_x_client becomes:

sub _build_x_client {
    my $self = shift;
    return SVN::Client->new(
       auth => [SVN::Client::get_simple_provider(),
                SVN::Client::get_simple_prompt_provider(
                     sub {
                          my $cred = shift;
                          $cred->username("fog");
                          $cred->password("bank");
                     },
                     2
                ),
                SVN::Client::get_username_provider()]);
}

I'm not that sure how to leverage the .subversion auth info though - must be a 
way to read it in, or maybe the svn driver can already do this?

Original comment by pat.pode...@gmail.com on 11 May 2011 at 6:49

[GoogleCodeExporter]

it seems that without the correct credentials, none will be able to use 
subversion ever again....

Original comment by sm.case...@gmail.com on 11 May 2012 at 6:03

[GoogleCodeExporter]

Hello Pat,

I got same problem here, it seems VCI library failed to authenticate the 
subversion repository.It ignoring the local svn credentials in the homedir. 
I am not familiar with VCI api,so I got stuck here. I googled it and didn't 
find hint for this issue.

Did you manage to resolve this issue?
Maybe patch?

Thanks,

Assaf R

Original comment by assaf...@gmail.com on 3 Dec 2012 at 8:43

[GoogleCodeExporter]

I had to struggle with it.... I had to update the Svn.pm and the 
lib/VCI/VCS/Svn/Repository.pm:

has 'x_ra' => (is => 'ro', isa => 'SVN::Ra', lazy => 1,
               default => sub { SVN::Ra->new(
                                         url => shift->x_root_noslash,
                                         auth =>     [                   SVN::Client::get_simple_provider(),
                                                          SVN::Client::get_simple_prompt_provider
                                                     (
                                                        \&getauth,2
                                                     ),
                                                     SVN::Client::get_username_provider()
                                                  ],

              );
              });

Original comment by assaf...@gmail.com on 4 Dec 2012 at 3:15

[GoogleCodeExporter]

...also, another important feature missing is the ability to make the "commits" 
private, as comments are.

After digging some more I found it:

edit this file:
./bugzilla/extensions/VCS/template/en/default/hook/bug/edit-after_custom_fields.
html.tmpl

i.e.

   [%IF user.is_insider %]

[% RETURN UNLESS bug.vcs_commits.size %]
<tr id="commits">
  <th class="field_label commits_label">
    <a href="#commits">[% field_descs.vcs_commits FILTER html %]:</a>
  </th>
  <td></td>
</tr>
<tr>
  <td colspan="2">
          <div class="bz_private_checkbox">
            <input type="hidden" value="1"
                   name="defined_isprivate_[% comment.id %]">
          </div>
      [% PROCESS "vcs/commits.html.tmpl" %]
     </div>
   </td>
</tr>
   [% END %]

I hope I earned my two cents...   ;)

Assaf

Original comment by assaf...@gmail.com on 4 Dec 2012 at 3:21