subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Mrkva <m...@justinmrkva.com>
Subject Re: AuthUserFile not specified in the configuration
Date Fri, 04 Apr 2014 10:54:39 GMT
Yes, it is readable. I also confirmed the command works.

In the meantime, I’ve tried a few additional things. I found a preinstalled (but unactivated)
module called mod_auth_digest_apple, so I deactivated mod_auth_digest in favor of the Apple-specific
one. There’s one important difference: the Apple version does _not_ need the AuthUserFile.
Instead, it uses the OS X user database. Oddly, Apache still complains about AuthUserFile,
but it succeeds. I expect it masquerades as mod_auth_digest for compatibility, so Apache still
expects the file to be specified even though it’s not needed.

Before, authentication succeeded in the browser but gave the error and returned 500 for the
client. Now, authentication seems to succeed on _both_ the browser and the client, which is
a step in the right direction I guess.

However, there’s a new error on the client instead of a 500:

    svn: E175013: Access to 'https://server.example.com/svn/repo' forbidden

This error again only occurs for the client, the browser is still able to browse repos with
no trouble. I confirmed again that all files (such as /Library/Subversion/svnaccess) are properly
readable. Additionally I modified svnaccess to remove rw permissions, refreshed the browser,
and the repos disappeared from the listing. Reenabling rw for my user or for all users caused
it to appear again, so it is definitely obeying the svnaccess file.

As for the OPTIONS request being treated differently somehow, that is… actually very possible.
I set LogLevel in httpd.conf to debug and watched the error messages, but I never saw anything
that looked suspicious. I’ve pasted the httpd.conf file at https://gist.github.com/anonymous/d84e4e9721a49789f846
if someone wants to take a look.

I did try using curl to send GET and OPTIONS requests to the /svn/ path of the server. GET
responded with 200, OPTIONS responded with a 403. So that looks like the problem. I have no
idea how to fix it, though.

A small excerpt of just the SVN relevant sections of httpd.conf:

    LoadModule auth_digest_apple_module ${SERVER_INSTALL_PATH_PREFIX}/usr/libexec/apache2/mod_auth_digest_apple.so
    LoadModule dav_svn_module /usr/local/libexec/mod_dav_svn.so
    LoadModule authz_svn_module /usr/local/libexec/mod_authz_svn.so
    Location /svn/>
        DAV svn
        SVNParentPath /Library/Subversion/Repositories
        SVNListParentPath on
        
        AuthName "UserWebDAV Gateway"
        AuthType Digest
        AuthzSVNAccessFile /Library/Subversion/svnaccess
        Require valid-user
        
        Order allow,deny
        Allow from all
    </Location>

On Apr 4, 2014, at 6:06 AM, Ryan Schmidt <subversion-2014@ryandesign.com> wrote:

> 
> On Apr 4, 2014, at 04:24, Daniel Shahaf wrote:
> 
>> Does 'sudo -u _www wc -l -- /private/etc/svnauth.htdigest' work?
>> 
>> (I'm suspecting /private might be unreadable by _www.)
> 
> On a normal OS X system, /private and /private/etc have rwxr-xr-x permissions.
> 


Mime
View raw message