I'm trying to linking the SVN hosted on Apache on a Windows Server 2008 to the Active Directory.
I understood what do I need to do to manage the groups of users on repository level:
<Location "/SampleRepository1">
DAV svn
SVNPath H:/Repositories/SampleDirectory1
AuthBasicProvider ldap
AuthzLDAPAuthoritative Off
AuthLDAPURL "ldap://.../DC=...,DC=com?sAMAccountName?sub?(objectClass=*)" none
AuthLDAPBindDN "CN=Subversion,OU=Subversion,DC=...,DC=com"
AuthLDAPBindPassword "..."
AuthType Basic
AuthName "Use your sAMAccountName to connect. If you're unsure, write to [email protected]."
require ldap-group CN=Subversion OpenSource Contributors,OU=Subversion,DC=...,DC=com
require ldap-group CN=Subversion Administrators,OU=Subversion,DC=...,DC=com
</location>
<Location "/SampleRepository2">
DAV svn
SVNPath H:/Repositories/SampleDirectory2
AuthBasicProvider ldap
AuthzLDAPAuthoritative Off
AuthLDAPURL "ldap://.../DC=...,DC=com?sAMAccountName?sub?(objectClass=*)" none
AuthLDAPBindDN "CN=Subversion,OU=Subversion,DC=...,DC=com"
AuthLDAPBindPassword "..."
AuthType Basic
AuthName "Use your sAMAccountName to connect. If you're unsure, write to [email protected]."
require ldap-group CN=Subversion Administrators,OU=Subversion,DC=...,DC=com
</location>
What bothers me is that there is too mach duplication: if SVNPath
and ldap-group
s change from repository to repository, everything else remains the same.
How to avoid duplicating code while being able to authorize some repositories to different groups?
Your concerns stem from viewing Apache's configuration as code; it isn't. You'll drive yourself crazy if you think of it from that perspective.
There's no logic structure, only some rudimentary conditional constructs on certain individual commands, and next to no variable manipulation. All of the things that let a programming language empower you to avoid code duplication and improve logic flow simply aren't present, by design; it's just a config file, after all - some would argue that it's too flexible (and thus, too easy to turn a configuration into a huge nonsensical mess) as is.
That said, you can reduce out a lot of the config that you've got there by just applying some of your directives to a parent of that URL path; assuming that you can safely apply these directives to
/
, and that these directives apply to every repository in the system:All
<Location>
blocks that match to a request will apply their directives to it (in the order that the file has them in), which means that you can split a lot of the common config out into an applicable parent path.