1 |
Intro: |
2 |
|
3 |
Okupy is a Django CMS, with a full LDAP frontend, XML to HTML (and the |
4 |
opposite) converter and a WYSIWYG editor, Beacon, to edit the XML files. |
5 |
Ultimate goal is to fully replace current Gentoo website, and Gorg, the web |
6 |
server that does the XML to HTML convertion currently. In the future I'd like |
7 |
to see more gentoo websites being provided by Okupy. |
8 |
|
9 |
Summary: |
10 |
|
11 |
The application has a fully working and fully configurable LDAP backend. It can |
12 |
work with any LDAP configuration file, but it will need accordingly some setup |
13 |
in Okupy's settings files. It currently supports: |
14 |
|
15 |
- Creation of a new user, which means that the Gentoo LDAP server can now be |
16 |
enabled for non-developers |
17 |
- Log in of current users, using any of their verified emails |
18 |
- Adding new email, along with email verification |
19 |
- Password reset |
20 |
- View someone's account data (based on the privileges, the according |
21 |
attributes will show up) |
22 |
- Edit own account data (again, based on privileges, the according attributes |
23 |
will be available for editing) |
24 |
- An addressbook |
25 |
In order to support all users and not only developers, I had to do some |
26 |
internal infra discussions about which OU will be used for them. Plus, a few |
27 |
new values were needed for the GentooAccess attribute, such as user.group, |
28 |
docs.group and other privileged groups. Most LDAP backends were using an |
29 |
administrator account for performing both queries and changes in the data, |
30 |
which could easily lead to a security issue. This problem was solved by using |
31 |
a secondary password for the user, which is encrypted and stored in the |
32 |
session variable. The secondary password is available for only one session, |
33 |
and gets destroyed by using itself. Django uses a database to store users, but |
34 |
it also supports other backends for the authentication part. When the user |
35 |
logs in for the first time, the data gets transfered in the database, which is |
36 |
a significant time improvement. Anonymous common LDAP Queries are performed |
37 |
either by using a minimal privileged (anon) account, or they should be |
38 |
available to anyone (which could lead to a security issue). I used some |
39 |
wrappers to cover that easily. The administrator can use a lot of options in |
40 |
the settings files, to cover the ACL part, the initial user creation and many |
41 |
other aspects. |
42 |
|
43 |
As I said in my previous post, Beacon didn't work out as expected. It became |
44 |
too complex, consisting of lots of JS and XSLT, for reading the XML files and |
45 |
printing them. It even stores accounts in its own DB to keep track of the |
46 |
documents that users edit. This was way out of our needs, we just need the |
47 |
WYSIWYG part only and plug it in in a separate web app. Obviously in its |
48 |
current state it is not a workable solution without significant additional |
49 |
effort. I tried to split some parts of its code, like the python scripts for |
50 |
converting XML to HTML and the opposite, but the time was not sufficient. |
51 |
|
52 |
The future: |
53 |
|
54 |
I am really happy to have such an interesting pet project now. I created an |
55 |
ebuild in my personal overlay, and an alias (okupy at gentoo dot org) to |
56 |
easily contact me for future issues. I plan to make it more accessible to some |
57 |
people soon, but not before Robin ACKs it first, since the LDAP server he gave |
58 |
me for testing is full of real data. I don't feel very confident on working |
59 |
with that, and I'll possibly request an empty one. |
60 |
|
61 |
Before implementing, it will need too much work. Most importantly, people |
62 |
familiar with Web Design are very welcome to help on this. If we are going to |
63 |
redesign the current gentoo.org website, it is a huge step that has to be done |
64 |
very carefully. The LDAP part although finished will need too much testing, in |
65 |
order to assure we are not opening any security holes here. As for the Beacon |
66 |
part, it will need better approach, and most of the work has to be done |
67 |
upstream, which is what I intend to do from now on. It should become a single |
68 |
JS WYSIWYG editor that we should be able to plug in directly, since it |
69 |
currently is a full web application, which is using its own DB to store users |
70 |
and documents. |
71 |
|
72 |
If you are interested in testing it, please contact me directly for now. The |
73 |
installation is not very easy at the moment, due to the need of both a |
74 |
database and an LDAP server, but it can work with minimal configuration for |
75 |
development purposes. I also added some config files in a separate branch for |
76 |
that reason. |
77 |
|
78 |
Many thanks to my mentor, Matthew Summers, my co-mentor Robin Johnson, and the |
79 |
Gentoo GSoC admin Donnie Berkholz for all their help and support. Also, |
80 |
special thanks to Ben Cooksley, KDE Sysadmin, for his precious suggestions. |
81 |
-- |
82 |
Theo Chatzimichos | blog.tampakrap.gr |
83 |
Gentoo KDE/Qt, Planet, Overlays |