Web publishing system with Apache and Subversion – part 3
Authorization
The previous posts were covering setup and authentication. But definitely you would like special rules for different groups and modules in your organization. It is not uncommon that a different group of developers will work on different module(s).
For this you have to use the mod_authz_svn
module that comes with the Subversion module and activate it by adding the below line at the beginning of <apache-dir>/conf/extra/wps.conf
:
LoadModule authz_svn_module modules/mod_authz_svn.so
Then to configure the access policy you have to add to every <Location>
section that defines Subversion repositories:
AuthzSVNAccessFile "/wps/svnaccess.conf"
where /wps/svnaccess.conf
is the file holding your access policy.
I will try now to explain the syntax and semantic of this access policy file using a small example:
[groups] admins = admin1, admin2 web-developers = john, marry backstage-developers = harry, sally [/] * = @admins = rw [web:/] @web-developers = rw @backstage-developers = r editor = rw [stage:/] @web-developers = rw @backstage-developers = rw
You can see that the file is an usual properties files divided in sections, each section beginning with [<section-title>]
and ending at the beginning of the next section. The first section defines the groups of users. The users in group are comma separated. It is obvious that john and marry are web developers and there are two administrators (admin1, admin2).
The following sections describes access rules to repositories and directories. The section title has the format repository:path
and it specifies a rule for the given path inside the repository. If you don’t specify a repository or a path it will define the rules for all (repositories/paths). Inside these sections every line describing an access rule has the format
username = permissions
or
@groupname = permissions
If the username
is *
, then it refers to all the users.
The permission can be an empty string for granting no permission, r
for reading, w
for writing and rw
for reading/writing.
Taking into account all this you can see that by default nobody has access to the repositories and administrators have read/write access to everything. Further on, the backstage developers have read access to the website and read/write access to the backstage environment.
More information on these you can find on the SVN book in the section Per-Directory Access Control.
Backstage environment
You already saw that I used the term backstage. This refers to a website with access only for the internal users that it is used for reviewing purposes. Before putting something on your website you may want to be reviewed by certain groups and modified accordingly. Of course we will also have a corresponding Subversion repository as for the main website.
So we will do the same creation of the Subversion repository, create the directory for the web folder, checkout the repository, add the hook and configure Apache. I will only explain here how to write the configuration for Apache, as this is a little bit different because it should be only accessible for internal users. Practically you will add the same authentication configuration as for the Subversion repositories.
<Directory "/wps/backstage"> AllowOverride None Options None Order allow,deny Allow from all AuthName "Backstage Authentication" Require valid-user # for basic authentication AuthType basic AuthUserFile /wps/passwd </Directory> Alias /backstage /wps/backstage ScriptAlias /backstage/cgi-bin/ "/wps/backstage/cgi-bin/" # # Use name-based virtual hosting. # NameVirtualHost *:80 <VirtualHost *:80> ServerAdmin administrator@domain.com DocumentRoot "/wps/backstage" ServerName backstage.domain.com ServerAlias www.backstage.domain.com ErrorLog "logs/backstage.log" ScriptAlias /cgi-bin/ "/wps/backstage/cgi-bin/" </VirtualHost>
Conclusions
If we go back to the first post from this series then you can see that we met all the requirements for the desired web publishing system. It is free, OS independent and can be easily installed and setup (a few hours even for the very junior administrators).
The authentication and authorization mechanism can be customized to a very high degree to meet your needs.
Web developers can easily access the Subversion repository using TortoiseSVN. Or even from Dreamweaver (although this extension isn’t free and I haven’t tested it).
If you also install websvn, you will RSS feeds for all the changes made to your website.
And, most importantly, you have all the versioning system advantages brought to your website.
Web publishing system with Apache and Subversion – part 2
If you read the first part of this post, you probably know by now how to install and configure a web publishing system using only Apache and Subversion. But your system will miss one of the most important thing: authentication. So let’s get started and tackle this.
Authentication
We kept all the Apache configuration settings related to Subversion and the website in the file <apache-dir>/conf/extra/wps.conf
and further on we will modify this file.
Remember the below section located either in the main server or in a virtual one section?
<Location /svn > DAV svn SVNParentPath /wps/svnrepo SVNListParentPath On </Location>
We will modify this one to add authentication and authorization.
<Location /svn > DAV svn SVNParentPath /wps/svnrepo SVNListParentPath On AuthType basic AuthName "SVN repository" AuthUserFile /wps/passwd Require valid-user </Location>
The user database will be kept in the plain text file /wps/passwd
. To add or modify users you can use the htpasswd
utility. So let’s add a developer account:
htpasswd -c /wps/passwd developer
You will be prompted for the password. Later on you can change it with:
htpasswd /wps/passwd developer
.
There are also some other ways to authenticate users, by keeping the users in a database file or using LDAP. You have to specify the authentication provider and use the specific module settings: mod_authn_file
, mod_authn_dbm
,
mod_authn_dbd
,
and mod_authnz_ldap
.
Windows authentication
You can also use Windows domain authentication, but this will require just a little bit more work from your side. Anyway this may come in handy in some big organizations, where you don’t want to create special accounts only for this and enable users to use their usual Windows logon credentials.
First of all you have to download the SSPI authentication module and copy it to <apache-dir>/modules
. Then add the following line at the beginning of <apache-dir>/conf/extra/wps.conf
:
LoadModule sspi_auth_module modules/mod_auth_sspi.so
and the below lines to the Location
section corresponding to the SVN repository:
AuthName "Windows Authentication" AuthType SSPI SSPIAuth On SSPIAuthoritative On # set the domain to authorize against SSPIDomain your.windows.domain # keep domain name in userid string SSPIOmitDomain On SSPIUsernameCase lower SSPIOfferBasic On # basic authentication shouldn't # have higher priority SSPIBasicPreferred Off Require valid-user
Now lets’ discuss in a little bit more in detail the above configuration settings:
SSPIAuth
– this will turn on/off the Windows authentication moduleSSPIAuthoritative
– this will turn on/off if the the Windows authentication is mandatory or if other modules can be used as a fallbackSSPIDomain
– the IP address or name of your windows domain controller against which the authentication is runSSPIOmitDomain
– if it is On then the domain name is omitted from the user name; so if the user isDOMAIN\user
, the user name for Apache and Subversion will actually beuser
and notDOMAIN\user
.SSPIUsernameCase
– tells how the user name letter cases are converted. The possible values arelower
andupper
. If this is not specify then no conversion is made. If you specifylower
(recommended) then the user nameDOMAIN\User
will be transformed todomain\user
(if you also specifySSPIOmitDomain On
, then the name will becomeuser
)SSPIOfferBasic
– SSPI by default uses NTLM, a Microsoft proprietary protocol which only IE (and other Windows components/application) understand, so they are able to authenticate you automatically. If you setSSPIOfferBasic On
means that it is still authenticating against your Windows domain on the backend, but when it asks the client for a password, it does so using standard HTTP Basic authentication. So if you plan to use other clients to your Subversion repository than IE you must set this on and the client then will prompt you for the domain name and password. This is definately needed if you use TortoiseSVN.SSPIBasicPreferred
– if it is On then basic authentication will have higher priority
The authentication possibilities are endless and are depending only on your imagination and needs. I was focusing on these two types as they will probably appear more often: basic in a low or mid-size company and Windows authentication can be smoothly integrated in a big company infrastructure with Windows desktops for the big part of users.
Authorization, setting up a second repository and conclusions will follow soon.
Web publishing system with Apache and Subversion – part 1
Introduction
What does a versioning system have to do with the web and more specifically with a publishing system?
When developing small websites (mainly presentation ones) you usually don’t need a versioning system. This post will come very handy to you if you work on a bigger team developing an enterprise (not necessarily, presentation) website. There a versioning system is clearly needed: user concurrency, history backup, a central repository, basically the main features of such a system.
I have chosen Subversion as the concurrent versioning system, not only as being the latest in style ;), but also for some features which makes it perfect, easy to use and easy to setup. In a few words we want a web publishing system that:
- mandatory: is free
- mandatory: is easy to setup for administrators
- mandatory: is very easy to use for (web) developers
- mandatory: features versions for the web pages, so you will be able to see changes in time and revert to previous versions
- mandatory: provides an authentication and authorization system
- nice to have: the authorization system can be configured per module, meaning that different groups of developers can have read/write access to different sections of the website
- nice to have: able to send notifications every time a web page is modified
- nice to have: is customizable and able to perform specific tasks whenever a change is made (add/edit/delete web pages)
- nice to have: running on multiple OSes
Taking all this into account, what is the solution? I will continue by describing the steps how to setup and use such a system.
Installation
First of all, download and install Apache 2.2 and Subversion. The installation is very easy and I will not enter here in any details (there are even binary packages, aka installers, for all the main operating systems:) ).
Configuration
Now let’s get to the server configuration. For the sake of the example, let’s suppose that we will use the /wps
or c:\wps
(for Windows) folder for the entire thing. We will create the svnrepo
subfolder as a parent for all Subversion repositories and then create a Subversion repository for the website using the svnadmin
command:
svnadmin create /wps/svnrepo/web
or in Windows
svnadmin create c:\wps\svnrepo\web
Let’s go now and configure Apache so that you can access Subversion repository through it. We don’t use the lightweight svnserve standalone server because we already have Apache installed as a web server. The configuration steps are:
- Copy the files
mod_dav_svn.so
andmod_authz_svn.so
from<svn-dir>/bin
to<apache-dir>/modules
, where<svn-dir>
is the Subversion installation directory and<apache-dir>
is the Apache installation directory (usuallyC:\Program Files\Apache Software Foundation\Apache2.2
in Windows). - Add the following line to the Apache configuration file
<apache-dir>conf/httpd.conf
:
Include conf/extra/wps.conf
- Create and edit with your favorite text editor the file
<apache-dir>conf/extra/wps.conf
.Paste the below content into:
LoadModule dav_svn_module modules/mod_dav_svn.so LoadModule authz_svn_module modules/mod_authz_svn.so <IfModule dav_svn_module> # if the module was loaded succesfully # to exclude SVN files from web published folders <Directory ~ "/.svn"> Order allow,deny Deny from all </Directory> # if you want a virtual host for Subversion <VirtualHost *:80> ServerAdmin administrator@domain.com ServerName svn.domain.com <Location / > DAV svn SVNParentPath /wps/svnrepo SVNListParentPath On </Location> ErrorLog "logs/wps.log" </VirtualHost> # the Subversion folder <Location /svn > DAV svn SVNParentPath /wps/svnrepo SVNListParentPath On </Location>
If you restart your Apache web server you will be able to access the SVN repository at http://domain.com/svn/web or at http://svn.domain.com/web.
Now we will create a web
folder to host the website files and then checkout the web repository into it. Note that if you’re going to use a trunk/tags/branches
directory organization (which I definately recommend) in the repository then you should checkout in the web
folder only the trunk
:
svn checkout http://domain.com/svn/web/trunk /wps/web
As you noticed by now the /wps/web
is a working copy of the repository. But checking out the repository is not enough, you have to set up a commit hook to automatically update the working copy every time a change is made. Create a file post-commit
in Unix (don’t forget to change the x mode – chmod 775 post-commit) and post-commit.bat
in Windows with the following content:
svn update /wps/web
Every time a change is commited into the Subversion repository that change gets into the web
directory too. Of course a .svn
directory is created under each directory. You don’t have to delete them, the Directory ~ "\.svn"
Apache section in wps.conf
will deny access to these directories.
Now you have only to add a few lines to wps.conf
to enable access to the web
folder:
DocumentRoot "/wps/web" ServerAlias www.domain.com <Directory "/wps/web"> Options Indexes FollowSymLinks AllowOverride None Allow from all </Directory>
Note: Please don’t forget to restart Apache every time you change the configuration files.
Now everything should be up and ready. But everyone can commit to your web repository and you definately don’t want this.
In the next parts I will explain how to setup an authentication and authorization system and how to create a second web repository accessible only within your organization.