I have read and tested some more libs.

My concern is that:

django-ldapdb (http://opensource.bolloretelecom.eu/projects/django-ldapdb/):
amazing idea, I'm working very well to query users, having some issues to
write on LDAP but is more probably due server stuff and not django-ldapdb
itself. Probably django-ldapdb is a good start for a backend, but doesn't
have much documentation, mostly examples only.

django-auth-ldap (doc at http://packages.python.org/django-auth-ldap/,
source at https://bitbucket.org/psagers/django-auth-ldap): testing now, the
docs show that it's amazing with all backend and update of users working
very well at user login. This kind of functionality is required for me.

Since ldapdb can search, update and add users as I see in code we just need
to do some work on lookups and doc, because istartswith as example doesn't
works, but it is not much trouble I guess. At other side ldapdb lacks a
authentication backend that can update user data at login and is easy to
update django tables like auth-ldap does (see documentation). I'll use both
for now because my time about it is very small but in future I'm ready to
join on efforts to merge both apps and construct a full ldap backend / ldap
orm for django.



Felipe 'chronos' Prenholato.
Linux User nº 405489
Home page: http://chronosbox.org/blog
Twitter: http://twitter.com/chronossc



2011/3/21 David De La Harpe Golden <david.delaharpe.gol...@ichec.ie>

> On 03/11/10 07:48, sebastien piquemal wrote:
>
> > I have thought of many solutions to replace ldapdb. I came to
> > conclusion than the cleanest, and most useful for the community, would
> > be to implement a real db backend for ldap. However, I have been told
> > that it is an awfully big task !
> >
>
> It would be big...
>
> BTW "pumpkin" is another project that attempts an ORM-like (let's say
> ODM) interface.  It's not django integrated, i.e. it's not a ldap-nonrel
> backend for the Django ORM, it's a separate Somewhat-Django-ORM-like
> ODM.  http://pypi.python.org/pypi/pumpkin/0.1.0
>
> I'd also recommend taking a close look at ldap.schema.models in
> python-ldap source itself - it's "half an ODM" in itself, though it
> can't save and still doesn't really datatype-map (python-ldap is a thin
> layer on top of libldap and returns strings e.g. you get a "FALSE" back
> not a python False. Yeargh), it does introspect the schema and handle
> some horrible little details of attribute lookup for you.
>
> We also grew something of an ODM for in-house use, sitting on top of
> python-ldap, doing a little mapping of datatypes (only just enough for
> our needs), allowing saving.  It's unreleased at time of writing and,
> um, what happens to it later won't be up to me.  Pumpkin is probably
> better anyway.  Our Django ORM integration, such as it is, is by "fake"
> surrogate django models in RDBMS.  So again not a /backend/ for the
> django ORM - Instead we (ab)use entryUUID and syncrepl entryCSN ldap
> operational attributes to keep some almost featureless "LDAPEntry" model
> instances in the RDBMS roughly in-sync via polling*.  This allowed
> signals to fire etc so a django/celery based system can be somewhat
> reactive to directory changes both inside and  outside its control.  But
> our ldap directory is and will remain fairly small (thousands to tens of
> thousands of entries) having an RDBMS row for every entry in ldap works
> out okay, you wouldn't want to do it that way with a giant directory.
>
> (* We toyed with the idea of making a full-blown syncrepl client on top
> of python-ldap for something lighter weight than polling, but that's not
> a small job either.  And there's some support in openldap for having
> /slapd backend to RDBMS/, i.e. swap the problem around, but it's limited
> and really only suited for specific setups...)
>
> P.S. ldaptor also exists and is a pure-python lowlevel ldap interface
> (unlike python-ldap which is on top of openldap libldap, so fully
> bug-compatible with libldap)
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-users@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Reply via email to