Visual Svn Server: how to restrict editing to specified IP address
I only want to enable a specific IPAddess to edit (add, remove, update ...) my visual svn server, but all other IPAddess should be able to read ...
I believe this is needed in the file %VISUALSVN_SERVER%conf\httpd-custom.conf
<VirtualHost *:80>
<Location /svn>
# write access
<LimitExcept GET PROPFIND OPTIONS REPORT>
Order deny,allow
deny from all
Allow from XXX.XXX.XXX.XXX
</LimitExcept>
</Location>
</VirtualHost>
but don't know well visual svn server. What's the correct way?
Visual SVN Server 3.2 x64
installed in Windows 2008 R2 Server x64
UPDATE from VisualSvn support
This feature is not available out of the box in VisualSVN Server 3.2, but we are considering implementing it in a future release. [...] Generally speaking, it is possible to implement IP Based Restrictions by modifying the httpd-custom.conf file, however we strongly reject this approach. VisualSVN Server has the "SVNPathAuthz short_circuit" option enabled, which dramatically improves authorization performance. The option has a limitation, though: the server configuration must not rely on other authorizations such as "authz_host_module" (which is responsible for IP-based checks), otherwise you will run into unexpected behavior with authorization. On the other hand, if you turn off "short_circuit", you will certainly notice a performance degradation when you run authorization-dependent operations against your repos (for example,launch
svn log
,svn checkout
, `svn export, etc. or launching a graphical repository browser such as the one TortoiseSVN client provides)
source to share
Since SVN doesn't have built-in support, you can find a workaround.
You can configure the SVN server to use authentication and then only allow selected authenticated users / groups and leave everyone read-only. Security can be hardened in IIS and SSL / TLS can be used easily, and you can even detect and block brute-force password attempts if that is your main reason for considering IP filtering.
If IP filtering is required for some reason , I would suggest having a different SVN server instance (which runs on a different IP port) and making a repository copy for that instance (use svn dump on the master instance, then svn download your instance read-only 2). Then your firewall allows the participants (who are filtered by IP) access to the main SVN server, and all other IPs can access the SVN server instance read-only.
With svn dump and upload, you actually copy everything - all commits, history, comments, etc. You can do this as often as you like, and you can also bind these actions to the post-commit hook so that it happens after every commit.
source to share