Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We have a BitNami SVN stack running on a Windows machine which holds our SVN repository. It's set up to authenticate against our AD server and uses authz to control rights.

We need to be able to access it via a web browser from http://[domain]/svn. The domain name points to a linux environment that we're decommissioning, but until we do, other systems on that box prevent us from just re-pointing the domain record.

Currently, we've got a ProxyPass record on the linux machine to forward requests through to http://[machine name]/svn - it seems to work fine, and the endpoint machine asks for credentials, then authenticates: but when that happens, the access attempt is logged as coming from the linux box, rather than from the user who has authenticated.

It's almost like some element of the credentials aren't being passed through to the endpoint machine.

Has anyone done this before, or is there other info I can give to try to make sense of this problem, and figure out a way to solve it?


Will try to explain it differently -

Domain name => A: Apache server (linux) ==ProxyPass==> B: Apache/SVN server (windows)

The httpd.conf from the Windows SVN box is here:

Here's the apache conf on the linux box which is forwarding requests to [domain]/svn over to the SVN box:

# Proxy requests to SVN over to Windows SVN server
ProxyPass /svn
<Location /svn>

If you access the SVN box directly, the access log shows: - jason.standing [10/Dec/2012:19:04:36 +0000] "GET /svn/ HTTP/1.1" 200 361 - jason.standing [10/Dec/2012:19:04:38 +0000] "GET /svn/ HTTP/1.1" 200 361 - - [10/Dec/2012:19:04:52 +0000] "GET /svn HTTP/1.1" 401 401 - afaef [10/Dec/2012:19:04:54 +0000] "GET /svn HTTP/1.1" 401 401 - jason.standing [10/Dec/2012:19:05:02 +0000] "GET /svn HTTP/1.1" 301 225 - jason.standing [10/Dec/2012:19:05:03 +0000] "GET /svn/ HTTP/1.1" 200 361

If you access it via the domain name (and thus the forwarding), you get: - ukdevservice [10/Dec/2012:19:04:32 +0000] "OPTIONS /svn/Product/_Installers HTTP/1.1" 200 183 - ukdevservice [10/Dec/2012:19:04:32 +0000] "PROPFIND /svn/Product/_Installers HTTP/1.1" 207 704 - ukdevservice [10/Dec/2012:19:04:32 +0000] "PROPFIND /svn/Product/_Installers HTTP/1.1" 207 704 - ukdevservice [10/Dec/2012:19:04:32 +0000] "PROPFIND /svn/!svn/vcc/default HTTP/1.1" 207 392 - ukdevservice [10/Dec/2012:19:04:32 +0000] "PROPFIND /svn/!svn/bln/10024 HTTP/1.1" 207 451 - ukdevservice [10/Dec/2012:19:04:32 +0000] "REPORT /svn/!svn/vcc/default HTTP/1.1" 200 256

In both cases you must authenticate using username & password before accessing the site, however the latter case the credentials seem to be getting altered and the apparent SVN user is someone with elevated privileges. And we don't want that.

share|improve this question
Oh, meant to add - I decided to use the ProxyPass record on the linux box to forward the request rather than a 301 redirect, because I read that Tortoise freaks out if you try to redirect it. – Jason B. Standing Dec 10 '12 at 16:07

I'm not clear on what you believe to be the issue here, or rather, what you would want to happen differently than what you describe.

If you desire that the original SVN client's ip address is logged, and not the proxy server, I turned up the following possibility in a Google search:

LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
LogFormat "%{X-Forwarded-For}i %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" proxy

SetEnvIf X-Forwarded-For "^.*\..*\..*\..*" forwarded
CustomLog "logs/access_log" combined env=!forwarded
CustomLog "logs/access_log" proxy env=forwarded

Basically what would happen here is that if the X-Forwarded-For HTTP header is set (to an IP address, which it would be if its ever set), then use that IP address in the log, rather then the default.

share|improve this answer
Hi, thanks for that... – Jason B. Standing Dec 10 '12 at 17:58
Hi, thanks for that... it's not the logging that's the problem: it's the apparent username of the authenticated user, which is passed in to Tortoise. If I access http://[machinename]/svn and give it username fred.smith then in the Apache access log I see fred.smith (and SVN checkins are recorded against fred.smith). If I use http://[domain name]/svn and give username fred.smith, the access.log shows a generic username - even though in order to gain access I had to give the details for fred.smith – Jason B. Standing Dec 10 '12 at 19:12
Then I'm not sure. What is your apache and SVN logging configuration? – Jeff Warnica Dec 10 '12 at 20:33
I've added some more info to the description - does that make any more sense? The issue's not the logging. The issue is that when you access the SVN box via the proxied URL the apache server on it appears to recognise your entry as a different user. – Jason B. Standing Dec 12 '12 at 11:19

Be good to get a network capture (e.g. Wireshark) of an authenticated request from the windows server and the linux server. Wireshark for windows, tcpdump for linux.

Looks like <Location '/svn'> is using Basic authn so the username should be in the Authorization header (see and should be blindly passed along by the front-end linux ProxyPass.

What's in ssi.conf?

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.