Home > Software, Web > Web publishing system with Apache and Subversion – part 3

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.

Part 1Part 2

Download configuration files.

  1. August 11, 2014 at 1:57 pm

    Hi there, the whole thing is going well here and ofcourse every one is sharing data, that’s in fact fine, keep up writing.

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: