[gentoo-soc] Okupy - Report #1

[Theo Chatzimichos]

Hi list

my name is Theodore Chatzimichos, and I'm working on a Django CMS replacement 
for the gentoo.org website, which will offer an LDAP web frontend and Beacon 
Editor as WYSIWYG editor. For more about it, you can read this [1] blog post.

The past week I’ve been experimenting with LDAP mostly. I set up a clone of 
ldap1.gentoo.org (with fake data of course) at my home server, and gave a 
Cfengine patch to Robin, pending for review, in order to have the testing LDAP 
service to vulture (the soc.dev box). I also set up my git repo, and split the 
settings.py file in many files, under a settings/ dir. This is how the transifex 
guys and my mentor Matt do it, and this approach allows us to put the config 
files even in /etc for example.

My major goal was to finish the LDAP backend part, either by using an existing 
library or writing it from scratch. Finally, after taking a look at many 
libraries and implementations, I wrote my own. More specifically, what the 
Django LDAP authentication backend does is to override the default Django DB 
authentication backend. When a user logs in, the backend checks if the user 
exists in the LDAP server. In order to do the search, the OpenLDAP server has 
to provide either an account to do that (an “anonymous” account with minimal 
privileges, just to do those kinds of ldap queries) or allow anonymous 
searches. In case the account is being used, it has to be declared in the 
settings file. I took it one step further from what the other backends did 
actually: in a common ldap configuration, all users are under OU=users or 
something. I intend to split it though to OU=users and OU=developers, thus I 
allowed the backend to search in multiple organizational units, by converting 
the variable to a python list. If the query sends a result (meaning the user 
is found), then it tries to bind with the credentials provided in the login 
form. If it suceeds, then the user data (apart from the password) are 
transfered to the django db, where they are going to be used for the rest of 
the session. Django actually has only email, real name and username in its 
accounts, but it gives the opportunity to extend those by creating a profile. 
That is technically an extra table in the db, with the ability to add custom 
fields, really handy.

The major problem that I’ve faced with all those ldap backends was that they 
all asked for an admin account, and they performed all changes with that 
account. That is acceptable for user creations but not for all the other 
cases. If a user wants to change his data, he should be able to do it with his 
regular account. Another problem emerged here though. OpenLDAP asks for the 
password before every action and one solution was to do it that way. Bcooksley 
had another idea though, to create a second 50char password, which will stay 
only for one session, and will be destroyed using itself at the end. I liked 
that idea very much, as asking the password is not too user friendly in my 
opinion, and the web frontend looses its purpose. For important changes though 
the password will be required (that includes uploading a new SSH/GPG key, or 
resetting the password).

The LDAP backend is now working, which is really cool, I didn’t expect it to 
be done so fast. My next step is to write some tests and documentation, for 
which I’ll use sphinx. Also, I plan to continue working on the ldap web 
frontend, by finishing the login/signup systems, and the user settings page, 
and then start messing with the UI.

[1] http://blogs.gentoo.org/tampakrap/accepted-for-gentoo-gsoc-2011/

-- 
Theo Chatzimichos (tampakrap) | blog.tampakrap.gr
Gentoo KDE/Qt, Planet, Overlays