Monthly Archives: December 2008

Better TurboGears LDAP authentication

TurboGears doesn’t have built-in LDAP authentication. This is annoying. I couldn’t get soldapprovider.py as provided from the TurboGears identity recipes page to work out of the box for my project (validate_password() was never getting called), and I wanted it to use my LDAP directory for more than just password validation, so I wrote my own soldapprovider.py, starting from the TurboGears soprovider.py. Unlike the original soldapprovider.py, mine only uses SQLObjects for storing user-visit associations. Everything else, including user object attributes, group memberships, and permissions, is pulled from the LDAP directory.

In the case of this project, the users and groups are set up as in RFC 2307. Users have a structural object class of inetOrgPerson and some extra attributes from a custom auxiliary class, which, if present, will be set as attributes on the user object. Attributes, group memberships, and permissions are read once, when the user object is instantiated inside load_identity() or validate_identity(). The key identity.soldapprovider.user_safe_attrs selects which attributes are used, and how they’re transformed. As is, the key’s default value is a mapping of names to functions, so this might not be ready for external configuration through TurboGears .conf files, which look sort of like Python code but aren’t.

Permissions are implemented as groupOfNames objects and named with cn attributes. My directory only uses two permissions, can_modify_account for users that are trusted to change their own passwords and edit their own contact into, and admin_powers, which is exactly what it sounds like. These two were set up so I could use them in ACLs in slapd.conf, which doesn’t support more complicated user-to-group mappings. I’m not entirely sure how permissions differ from groups in TurboGears other than in name, but this usage works for my app.

***

update:

This was written for TurboGears 1.0 and is no longer relevant, but I fixed a broken link to my soldapprovider.py anyway. All new development should be using TurboGears 2.0, which uses repoze for authentication and supports LDAP through repoze.

Advertisements
Tagged , , ,

ViewVC on DreamHost

I should start actually buying servers instead of recycling whatever boxes I have that would only be useful as footrests otherwise: bat-country.us was hosted on an old Power Mac G4 back at Caltech, but predictably, right after I left campus for Christmas break, it fell off the Internet, just like Turbine did all those years ago. Rather than harass some poor soul in Dabney into fixing it for me, I decided to move all my stuff into The Cloud, which seems to be the thing these days. Now the main site’s on DreamHost and the blog is this WordPress account which I forgot I had until finding an old bookmarks file the other day.

ViewVC has improved quite a bit since I was using it on Turbine, so now I’m using it again. Bernie Zimmerman has a handy page on getting it to work properly on DreamHost. The one bit he didn’t cover was mapping URLs to something more friendly.

Normally I’d just use Apache’s ScriptAlias directive to turn /viewvc.cgi/path/to/file into /code/path/to/file, but DreamHost doesn’t let you use ScriptAlias. They do allow mod_rewrite directives in .htaccess files, which covers the incoming URLs. My .htaccess looks like this:

RewriteEngine on
RewriteRule ^code/(.*)$ viewvc.cgi/$1
RewriteRule ^code$ viewvc.cgi

However, viewvc.cgi (the ViewVC entry point CGI script) needs to be told that it’s appearing to the user’s browser at the URL /code instead of the URL /viewvc.cgi, because otherwise all the links on pages generated by ViewVC point to the wrong place. Normally, ScriptAlias would take care of that by setting the SCRIPT_NAME CGI environment variable, but since I can’t use ScriptAlias, and ViewVC doesn’t seem to support any sort of config option that alters SCRIPT_NAME, I added the following line to the end of viewvc.cgi just before the main ViewVC code is invoked:

### complement to mod_rewrite
os.environ['SCRIPT_NAME'] = "/code"

# go do the work
import sapi
import viewvc

server = sapi.CgiServer()
cfg = viewvc.load_config(CONF_PATHNAME, server)
viewvc.main(server, cfg)

Problem solved.

Syntax highlighting in the beta version of ViewVC 1.1.0 that I’m using uses Pygments, and of course DreamHost’s Python installation doesn’t include Pygments. If you use Python on DreamHost, I highly recommend setting up a virtualenv wrapper for DreamHost’s Python, as described in the DreamHost wiki page on Python. First, I had to tell bash to look for executables in my own bin directory first:

export PATH="${HOME}/bin:${PATH}"
echo "export PATH=\"\${HOME}/bin:\${PATH}\"" >> ~/.bash_profile

Then I set up virtualenv wrappers for Python 2.5 and 2.4, in that order, which leaves the default python command pointing to 2.5 (a personal preference because it gives me the ternary conditional operator):

wget http://pypi.python.org/packages/2.4/v/virtualenv/virtualenv-1.3.2-py2.4.egg
unzip virtualenv-1.3.2-py2.4.egg
/usr/bin/python2.5 virtualenv-1.3.2-py2.4/virtualenv.py $HOME
/usr/bin/python2.4 virtualenv-1.3.2-py2.4/virtualenv.py $HOME

DreamHost’s Python 2.5 installation doesn’t have the Python bindings for Subversion, so I used 2.4, which does, for ViewVC purposes. (Don’t bother trying to build them for 2.5 unless you want to start from the very bottom: compiling stuff on DreamHost is a crapshoot, and my attempt crapped out while trying to link in some system library.) virtualenv comes with setuptools, so getting Pygments was a breeze:

easy_install-2.4 Pygments

The last step was changing the shebang/interpreter line at the top of viewvc.cgi from

#!/usr/bin/python

to

#!/home/my_username/bin/python2.4

to make CGI execution use the virtualenv version of Python 2.4 instead of the system’s Python, thus getting Pygments support and syntax coloring in ViewVC.

I only have one Subversion repository, so I wanted to suppress all the links to listing repository roots, to reduce visual clutter. This involved editing viewvc.conf to set default_root to my repository, disable root_as_url_component (which ignores default_root), and removing the roots view from allowed_views.

default_root = BatCountrySVN
root_as_url_component = 0
allowed_views = markup, annotate, co

I also had to tweak the newvc template I was using a bit, to remove the repository list references from the path navigation bar. Edited newvc/include/header.ext below vc_current_path to accomplish that, and done.

addition: ViewVC has an option to make Apache serve static content such as images and stylesheets, rather than serving them through the viewvc.cgi script, which is slower. I set

docroot = /viewvc_static

in viewvc.conf and then set up a mapping from http://bat-country.us/viewvc_static to /home/my_username/share/viewvc/templates/docroot using the DreamHost control panel (Domains ➔ Remap Sub-Dir).

Tagged , , , , , , ,

I’m back!

I forget whether it was at pricetrout.com (defunct), turbine.caltech.edu (defunct), or an even older and defuncter site, but I used to be #3 on Google for “crackpot rant”. I miss that.