2

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?

Thankyou!

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: http://pastebin.com/Pd5zrnyQ

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 http://10.2.1.142/svn <Location /svn> ProxyPassReverse http://10.2.1.142/svn </Location>

If you access the SVN box directly, the access log shows:

10.2.2.89 - jason.standing [10/Dec/2012:19:04:36 +0000] "GET /svn/ HTTP/1.1" 200 361 10.2.2.89 - jason.standing [10/Dec/2012:19:04:38 +0000] "GET /svn/ HTTP/1.1" 200 361 10.2.2.89 - - [10/Dec/2012:19:04:52 +0000] "GET /svn HTTP/1.1" 401 401 10.2.2.89 - afaef [10/Dec/2012:19:04:54 +0000] "GET /svn HTTP/1.1" 401 401 10.2.2.89 - jason.standing [10/Dec/2012:19:05:02 +0000] "GET /svn HTTP/1.1" 301 225 10.2.2.89 - 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:

10.2.1.252 - ukdevservice [10/Dec/2012:19:04:32 +0000] "OPTIONS /svn/Product/_Installers HTTP/1.1" 200 183 10.2.1.252 - ukdevservice [10/Dec/2012:19:04:32 +0000] "PROPFIND /svn/Product/_Installers HTTP/1.1" 207 704 10.2.1.252 - ukdevservice [10/Dec/2012:19:04:32 +0000] "PROPFIND /svn/Product/_Installers HTTP/1.1" 207 704 10.2.1.252 - ukdevservice [10/Dec/2012:19:04:32 +0000] "PROPFIND /svn/!svn/vcc/default HTTP/1.1" 207 392 10.2.1.252 - ukdevservice [10/Dec/2012:19:04:32 +0000] "PROPFIND /svn/!svn/bln/10024 HTTP/1.1" 207 451 10.2.1.252 - 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.

Improve this question
1
  • 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. Commented Dec 10, 2012 at 16:07

2 Answers 2

Reset to default
0

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.

Improve this answer
3
  • 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 Commented Dec 10, 2012 at 19:12
  • Then I'm not sure. What is your apache and SVN logging configuration? Commented Dec 10, 2012 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. Commented Dec 12, 2012 at 11:19
0

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 http://en.wikipedia.org/wiki/Basic_access_authentication) and should be blindly passed along by the front-end linux ProxyPass.

What's in ssi.conf?

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.