Menu
▾
▴
python-ldap-dev
|
From: James A. <ja...@da...> - 2007-10-22 12:53:52
|
Hi all,
The current Python LDAP interface is a bit low level for my liking, so
I've started work on an LDAP ORM[1]. Currently there's very little RM
going on, but I have got a nice Python object representing an LDAP
object with attribute access and deletion, no adding or saving to the
ldap server just yet. ldap.schema is really quite handy.
Which brings me to my next point - could someone update the API docs on
the website? They're 3.5 years out of date, and so missing things like
ldap.schema and cidict.
Here's a patch for cidict to implement __contains__, which makes foo in
somecidict work right:
--- cidict.py~ 2003-08-25 00:28:12.000000000 +0800
+++ cidict.py 2007-10-22 20:16:54.000000000 +0800
@@ -43,6 +43,9 @@
def has_key(self,key):
return UserDict.has_key(self,lower(key))
+ def __contains__(self,key):
+ return UserDict.has_key(self,lower(key))
+
def get(self,key,failobj=None):
try:
return self[key]
Anyway, I'd appreciate any comments or suggestions (including for a new
name) on LDAP ORM. I have a vague goal of being able to use LDAP as an
ORM for Django or whatever other web framework tickles your fancy.
[1] http://trs80.ucc.asn.au/ldaporm.py
James Andrewartha
|
|
From: <mi...@st...> - 2007-10-22 13:05:30
|
James Andrewartha wrote:
>
> --- cidict.py~ 2003-08-25 00:28:12.000000000 +0800
> +++ cidict.py 2007-10-22 20:16:54.000000000 +0800
> @@ -43,6 +43,9 @@
> def has_key(self,key):
> return UserDict.has_key(self,lower(key))
>
> + def __contains__(self,key):
> + return UserDict.has_key(self,lower(key))
> +
> def get(self,key,failobj=None):
> try:
> return self[key]
I'd prefer if it's ok for you:
def __contains__(self,key):
return self.has_key(self,key)
If you're using ldap.schema you might want to look into using class
ldap.schema.models.Entry instead of simply ldap.cidict.cidict because
you don't have to care about attribute description aliases and mapping
them to OIDs.
Ciao, Michael.
|
|
From: James A. <ja...@da...> - 2007-10-22 13:48:02
|
On Mon, 2007-10-22 at 15:05 +0200, Michael Ströder wrote: > James Andrewartha wrote: > > > > --- cidict.py~ 2003-08-25 00:28:12.000000000 +0800 > > +++ cidict.py 2007-10-22 20:16:54.000000000 +0800 > > @@ -43,6 +43,9 @@ > > def has_key(self,key): > > return UserDict.has_key(self,lower(key)) > > > > + def __contains__(self,key): > > + return UserDict.has_key(self,lower(key)) > > + > > def get(self,key,failobj=None): > > try: > > return self[key] > > I'd prefer if it's ok for you: > > def __contains__(self,key): > return self.has_key(self,key) Sure, I was just copying has_key(). > If you're using ldap.schema you might want to look into using class > ldap.schema.models.Entry instead of simply ldap.cidict.cidict because > you don't have to care about attribute description aliases and mapping > them to OIDs. I'm happy with the setup I've got now, but if I ever need to deal with attribute OIDs then I'll look into it. James Andrewartha |
|
From: James A. <ja...@da...> - 2007-10-22 16:55:28
|
On Mon, 2007-10-22 at 16:13 +0200, Michael Ströder wrote: > James Andrewartha wrote: > > On Mon, 2007-10-22 at 15:05 +0200, Michael Ströder wrote: > >> If you're using ldap.schema you might want to look into using class > >> ldap.schema.models.Entry instead of simply ldap.cidict.cidict because > >> you don't have to care about attribute description aliases and mapping > >> them to OIDs. > > > > I'm happy with the setup I've got now, but if I ever need to deal with > > attribute OIDs then I'll look into it. > > Well, it's not a matter of you personally need to deal with it. There > might be the case that an attribute type or object class does not have > NAME assigned at all. Also think about language sub-types and transfer > type ;binary separated by ; from the name. And dashes (-) are allowed in > AttributeTypeDescription. You really should dive into RFC 4512. Thanks for the pointer. I've updated the code to map _ in attribute names to -. Attributes without a short name are impossible to wrap - I'm not expecting clients of this library to know OIDs. Attributes with options are accessible via obj.['cn;lang-en'] (as are normal attributes). There should probably be some functions to ask for a specific language, RFC 3866 will guide me there. James Andrewartha |
|
From: <mi...@st...> - 2007-10-22 14:13:30
|
James Andrewartha wrote: > On Mon, 2007-10-22 at 15:05 +0200, Michael Ströder wrote: > >> If you're using ldap.schema you might want to look into using class >> ldap.schema.models.Entry instead of simply ldap.cidict.cidict because >> you don't have to care about attribute description aliases and mapping >> them to OIDs. > > I'm happy with the setup I've got now, but if I ever need to deal with > attribute OIDs then I'll look into it. Well, it's not a matter of you personally need to deal with it. There might be the case that an attribute type or object class does not have NAME assigned at all. Also think about language sub-types and transfer type ;binary separated by ; from the name. And dashes (-) are allowed in AttributeTypeDescription. You really should dive into RFC 4512. Ciao, Michael. |
|
From: James A. <ja...@da...> - 2007-10-22 16:26:23
|
On Mon, 2007-10-22 at 07:12 -0700, Anil Jangity wrote: > I was toying with the idea of doing just this thing a few days ago. > It'll be nice if it also handles all the modifications of an entry > with ease. (changing rdn when the attributes change etc...) > > Let me know how I can help. :) Well, have a look and see if what I've got so far seems sane, or if it needs more comments/explanation etc. > My main dev environment is pylons. Site doesn't work. > > ~ $ wget http://trs80.ucc.asn.au/ldaporm.py > --07:11:50-- http://trs80.ucc.asn.au/ldaporm.py > => `ldaporm.py' > Resolving trs80.ucc.asn.au... 130.95.13.9 > Connecting to trs80.ucc.asn.au[130.95.13.9]:80... connected. > HTTP request sent, awaiting response... 500 Internal Server Error > 07:11:51 ERROR 500: Internal Server Error. Oops, it wasn't supposed to be interpreted by the webserver. Try http://trs80.ucc.asn.au/ldaporm.pys instead. James Andrewartha |
|
From: <mi...@st...> - 2007-10-22 17:23:41
|
James Andrewartha wrote: > > Thanks for the pointer. I've updated the code to map _ in attribute > names to -. Attributes without a short name are impossible to wrap - I'm > not expecting clients of this library to know OIDs. If you don't support schema elements without NAME you're not LDAPv3 compliant. I saw schema elements without NAME and my web2ldap choked on this in the beginning. In this case the LDAP server returns the OIDs in search results. Ciao, Michael. |
|
From: James A. <ja...@da...> - 2007-10-28 10:14:44
|
On Mon, 2007-10-22 at 19:22 +0200, Michael Ströder wrote: > James Andrewartha wrote: > > > > Thanks for the pointer. I've updated the code to map _ in attribute > > names to -. Attributes without a short name are impossible to wrap - I'm > > not expecting clients of this library to know OIDs. > > If you don't support schema elements without NAME you're not LDAPv3 > compliant. I saw schema elements without NAME and my web2ldap choked on > this in the beginning. In this case the LDAP server returns the OIDs in > search results. Ok, I've added handling for them - they should end up being accessible by obj['9.9.9'], assuming the OID is returned as a string key in the results dictionary. Source is now available at http://forgetldap.svn.sourceforge.net/viewvc/forgetldap/trunk/ thanks to Gagatan on #luma. It now supports modification of an entry, although it doesn't change the rdn as yet. I'll probably look at that after I add support for saving changes back to the LDAP server. Anil - I've added some notes at the bottom of the source on the API the Django ORM expects, what does Pylons expect? James Andrewartha |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X