1 |
Hi list |
2 |
|
3 |
my name is Theodore Chatzimichos, and I'm working on a Django CMS replacement |
4 |
for the gentoo.org website, which will offer an LDAP web frontend and Beacon |
5 |
Editor as WYSIWYG editor. For more about it, you can read this [1] blog post. |
6 |
|
7 |
The past week I’ve been experimenting with LDAP mostly. I set up a clone of |
8 |
ldap1.gentoo.org (with fake data of course) at my home server, and gave a |
9 |
Cfengine patch to Robin, pending for review, in order to have the testing LDAP |
10 |
service to vulture (the soc.dev box). I also set up my git repo, and split the |
11 |
settings.py file in many files, under a settings/ dir. This is how the transifex |
12 |
guys and my mentor Matt do it, and this approach allows us to put the config |
13 |
files even in /etc for example. |
14 |
|
15 |
My major goal was to finish the LDAP backend part, either by using an existing |
16 |
library or writing it from scratch. Finally, after taking a look at many |
17 |
libraries and implementations, I wrote my own. More specifically, what the |
18 |
Django LDAP authentication backend does is to override the default Django DB |
19 |
authentication backend. When a user logs in, the backend checks if the user |
20 |
exists in the LDAP server. In order to do the search, the OpenLDAP server has |
21 |
to provide either an account to do that (an “anonymous” account with minimal |
22 |
privileges, just to do those kinds of ldap queries) or allow anonymous |
23 |
searches. In case the account is being used, it has to be declared in the |
24 |
settings file. I took it one step further from what the other backends did |
25 |
actually: in a common ldap configuration, all users are under OU=users or |
26 |
something. I intend to split it though to OU=users and OU=developers, thus I |
27 |
allowed the backend to search in multiple organizational units, by converting |
28 |
the variable to a python list. If the query sends a result (meaning the user |
29 |
is found), then it tries to bind with the credentials provided in the login |
30 |
form. If it suceeds, then the user data (apart from the password) are |
31 |
transfered to the django db, where they are going to be used for the rest of |
32 |
the session. Django actually has only email, real name and username in its |
33 |
accounts, but it gives the opportunity to extend those by creating a profile. |
34 |
That is technically an extra table in the db, with the ability to add custom |
35 |
fields, really handy. |
36 |
|
37 |
The major problem that I’ve faced with all those ldap backends was that they |
38 |
all asked for an admin account, and they performed all changes with that |
39 |
account. That is acceptable for user creations but not for all the other |
40 |
cases. If a user wants to change his data, he should be able to do it with his |
41 |
regular account. Another problem emerged here though. OpenLDAP asks for the |
42 |
password before every action and one solution was to do it that way. Bcooksley |
43 |
had another idea though, to create a second 50char password, which will stay |
44 |
only for one session, and will be destroyed using itself at the end. I liked |
45 |
that idea very much, as asking the password is not too user friendly in my |
46 |
opinion, and the web frontend looses its purpose. For important changes though |
47 |
the password will be required (that includes uploading a new SSH/GPG key, or |
48 |
resetting the password). |
49 |
|
50 |
The LDAP backend is now working, which is really cool, I didn’t expect it to |
51 |
be done so fast. My next step is to write some tests and documentation, for |
52 |
which I’ll use sphinx. Also, I plan to continue working on the ldap web |
53 |
frontend, by finishing the login/signup systems, and the user settings page, |
54 |
and then start messing with the UI. |
55 |
|
56 |
[1] http://blogs.gentoo.org/tampakrap/accepted-for-gentoo-gsoc-2011/ |
57 |
|
58 |
-- |
59 |
Theo Chatzimichos (tampakrap) | blog.tampakrap.gr |
60 |
Gentoo KDE/Qt, Planet, Overlays |