[gentoo-soc] Okupy - Final Report

[gentoo-soc] Okupy - Final Report

[Theo Chatzimichos]

[-- Attachment #1: Type: text/plain, Size: 4685 bytes --]

Intro:

Okupy is a Django CMS, with a full LDAP frontend, XML to HTML (and the 
opposite) converter and a WYSIWYG editor, Beacon, to edit the XML files. 
Ultimate goal is to fully replace current Gentoo website, and Gorg, the web 
server that does the XML to HTML convertion currently. In the future I'd like 
to see more gentoo websites being provided by Okupy.

Summary:

The application has a fully working and fully configurable LDAP backend. It can 
work with any LDAP configuration file, but it will need accordingly some setup 
in Okupy's settings files. It currently supports:

 - Creation of a new user, which means that the Gentoo LDAP server can now be 
enabled for non-developers
 - Log in of current users, using any of their verified emails
 - Adding new email, along with email verification
 - Password reset
 - View someone's account data (based on the privileges, the according 
attributes will show up)
 - Edit own account data (again, based on privileges, the according attributes 
will be available for editing)
 - An addressbook
In order to support all users and not only developers, I had to do some 
internal infra discussions about which OU will be used for them. Plus, a few 
new values were needed for the GentooAccess attribute, such as user.group, 
docs.group and other privileged groups. Most LDAP backends were using an 
administrator account for performing both queries and changes in the data, 
which could easily lead to a security issue. This problem was solved by using 
a secondary password for the user, which is encrypted and stored in the 
session variable. The secondary password is available for only one session, 
and gets destroyed by using itself. Django uses a database to store users, but 
it also supports other backends for the authentication part. When the user 
logs in for the first time, the data gets transfered in the database, which is 
a significant time improvement. Anonymous common LDAP Queries are performed 
either by using a minimal privileged (anon) account, or they should be 
available to anyone (which could lead to a security issue). I used some 
wrappers to cover that easily. The administrator can use a lot of options in 
the settings files, to cover the ACL part, the initial user creation and many 
other aspects.

As I said in my previous post, Beacon didn't work out as expected. It became 
too complex, consisting of lots of JS and XSLT, for reading the XML files and 
printing them. It even stores accounts in its own DB to keep track of the 
documents that users edit. This was way out of our needs, we just need the 
WYSIWYG part only and plug it in in a separate web app. Obviously in its 
current state it is not a workable solution without significant additional 
effort. I tried to split some parts of its code, like the python scripts for 
converting XML to HTML and the opposite, but the time was not sufficient.

The future:

I am really happy to have such an interesting pet project now. I created an 
ebuild in my personal overlay, and an alias (okupy at gentoo dot org) to 
easily contact me for future issues. I plan to make it more accessible to some 
people soon, but not before Robin ACKs it first, since the LDAP server he gave 
me for testing is full of real data. I don't feel very confident on working 
with that, and I'll possibly request an empty one.

Before implementing, it will need too much work. Most importantly, people 
familiar with Web Design are very welcome to help on this. If we are going to 
redesign the current gentoo.org website, it is a huge step that has to be done 
very carefully. The LDAP part although finished will need too much testing, in 
order to assure we are not opening any security holes here. As for the Beacon 
part, it will need better approach, and most of the work has to be done 
upstream, which is what I intend to do from now on. It should become a single 
JS WYSIWYG editor that we should be able to plug in directly, since it 
currently is a full web application, which is using its own DB to store users 
and documents.

If you are interested in testing it, please contact me directly for now. The 
installation is not very easy at the moment, due to the need of both a 
database and an LDAP server, but it can work with minimal configuration for 
development purposes. I also added some config files in a separate branch for 
that reason.

Many thanks to my mentor, Matthew Summers, my co-mentor Robin Johnson, and the 
Gentoo GSoC admin Donnie Berkholz for all their help and support. Also, 
special thanks to Ben Cooksley, KDE Sysadmin, for his precious suggestions.
-- 
Theo Chatzimichos | blog.tampakrap.gr
Gentoo KDE/Qt, Planet, Overlays

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-soc] Okupy - Final Report

[Domen Kožar]

[-- Attachment #1: Type: text/plain, Size: 5138 bytes --]

Hey!

This is really not a good timing and I was unfortunately not observing your
progress (so I may be left out on details), but did you take a look at
http://packages.python.org/django-auth-ldap/ ?

Cheers, Domen


On Thu, Aug 25, 2011 at 12:35 AM, Theo Chatzimichos <tampakrap@gentoo.org>wrote:

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

[-- Attachment #2: Type: text/html, Size: 5870 bytes --]