Announcing version 0.0.4 of Net::LDAP, the pure-Ruby LDAP library. Thanks to the many people who have used this library and sent in comments, suggestions, feature requests, and patches. An even bigger thank-you to the folks who have made themselves available to help with testing. Net::LDAP has been quite stable for several months now, so we bumped the development status of the library up to Beta. We will still be adding features and API improvements, but you can assume that the current APIs and features will remain stable. We''ve noticed that the Rails list gets regular chatter about authentication and authorization. To address what seems to be a clear need, we''d like to create some Rails integration (probably a plugin) based on Net::LDAP. I''d love to hear your ideas and insights on what would be the most useful set of features to provide. Additionally, we''re thinking ahead to adding presence and directory-aggregation to Net::LDAP, possibly through an additional set of packages. Version 0.0.4 adds an implementation of Net::LDAP#bind_as, which allows you to authenticate users who log into your applications using simple identifiers like email addresses and simple usernames. Thanks to Simon Claret for suggesting the original implementation in his page on the Rails-Wiki, and for valuable comments and help with testing. We have un-deprecated Net::LDAP#modify, which can be useful with LDAP servers that observe non-standard transactional and concurrency semantics in LDAP Modify operations. Note: this is a documentation change, not a code change. Thanks to Justin Forder for providing the rationale for this change. We added a larger set of special characters which may appear in RFC-2254 standard search filters. Thanks to Andre Nathan for this patch. We fixed a bug that was preventing Net::LDAP#open from being called more than once on the same object. Net::LDAP is a feature-complete LDAP client which can access as much as possible of the functionality of the most-used LDAP server implementations. This library does not wrap any existing native-code LDAP libraries, creates no Ruby extensions, and has no dependencies external to Ruby. If anyone wants to contribute suggestions, insights or (especially) code, please email me at garbagecat10 .. .. gmail.com. -- Posted via http://www.ruby-forum.com/.
Excellent! Keep up the good work. The Tivoli Directory Server saga continues on my current project - it''s impossible to meet the security architect''s requirements that we use TDS to implement password policy without deviating from the (signed-off) Functional Requirements Spec. regards Justin Francis Cianfrocca wrote:> Announcing version 0.0.4 of Net::LDAP, the pure-Ruby LDAP library. > > Thanks to the many people who have used this library and sent in > comments, > suggestions, feature requests, and patches. An even bigger thank-you to > the > folks who have made themselves available to help with testing. > > Net::LDAP has been quite stable for several months now, so we bumped > the development status of the library up to Beta. We will still be > adding > features and API improvements, but you can assume that the current > APIs and features will remain stable. > > We''ve noticed that the Rails list gets regular chatter about > authentication > and authorization. To address what seems to be a clear need, we''d like > to create some Rails integration (probably a plugin) based on Net::LDAP. > I''d love to hear your ideas and insights on what would be the most > useful > set of features to provide. Additionally, we''re thinking ahead to adding > presence > and directory-aggregation to Net::LDAP, possibly through an additional > set of packages. > > Version 0.0.4 adds an implementation of Net::LDAP#bind_as, which allows > you to authenticate users who log into your applications using simple > identifiers like email addresses and simple usernames. Thanks to Simon > Claret > for suggesting the original implementation in his page on the > Rails-Wiki, > and for valuable comments and help with testing. > > We have un-deprecated Net::LDAP#modify, which can be useful with > LDAP servers that observe non-standard transactional and concurrency > semantics in LDAP Modify operations. Note: this is a documentation > change, > not a code change. Thanks to Justin Forder for providing the rationale > for this change. > > We added a larger set of special characters which may appear in RFC-2254 > standard search filters. Thanks to Andre Nathan for this patch. > > We fixed a bug that was preventing Net::LDAP#open from being called more > than once on the same object. > > Net::LDAP is a feature-complete LDAP client which can access as much as > possible of the functionality of the most-used LDAP server > implementations. > This library does not wrap any existing native-code LDAP libraries, > creates no > Ruby extensions, and has no dependencies external to Ruby. > > If anyone wants to contribute suggestions, insights or (especially) > code, please email me at garbagecat10 .. .. gmail.com. >
Justin Forder wrote:> Excellent! Keep up the good work.> Francis Cianfrocca wrote:[...]>> We have un-deprecated Net::LDAP#modify, which can be useful with >> LDAP servers that observe non-standard transactional and concurrency >> semantics in LDAP Modify operations. Note: this is a documentation >> change, >> not a code change. Thanks to Justin Forder for providing the rationale >> for this change.The documentation comment for modify still says: "It?s essential to keep in mind that if you specify more than one operation in a call to modify, most LDAP servers will attempt to perform all of the operations in the order you gave them. This matters because you may specify operations on the same attribute which must be performed in a certain order. Most LDAP servers will stop processing your modifications if one of them causes an error on the server (such as a schema-constraint violation). If this happens, you will probably get a result code from the server that reflects only the operation that failed, and you may or may not get extended information that will tell you which one failed. modify has no notion of an atomic transaction. If you specify a chain of modifications in one call to modify, and one of them fails, the preceding ones will usually not be "rolled back," resulting in a partial update. This is a limitation of the LDAP protocol, not of Net::LDAP. The lack of transactional atomicity in LDAP means that you?re usually better off using the convenience methods add_attribute, replace_attribute, and delete_attribute, which are are wrappers over modify. However, certain LDAP servers may provide concurrency semantics, in which the several operations contained in a single modify call are not interleaved with other modification-requests received simultaneously by the server. It bears repeating that this concurrency does not imply transactional atomicity, which LDAP does not provide." whereas the LDAP RFCs are very clear that: - operations must be carried out in the order in which they were specified - the entire modify operation must succeed or fail atomically - individual operations within the set may violate the schema, so long as applying the whole set doesn''t. So, while it may be true that many LDAP servers don''t conform to the specification (you are the one with the experience here), it isn''t correct to say "this is a limitation of the LDAP protocol", or "...transactional atomicity, which LDAP does not provide". regards, and thanks for removing the deprecation Justin
Justin Forder wrote: > So, while it may be true that many LDAP servers don''t conform to the> specification (you are the one with the experience here), it isn''t > correct to say "this is a limitation of the LDAP protocol", or > "...transactional atomicity, which LDAP does not provide". > > regards, and thanks for removing the deprecation > > JustinWould you like to have a go at patching the document? -- Posted via http://www.ruby-forum.com/.
Francis Cianfrocca wrote:> Justin Forder wrote: > > So, while it may be true that many LDAP servers don''t conform to the >> specification (you are the one with the experience here), it isn''t >> correct to say "this is a limitation of the LDAP protocol", or >> "...transactional atomicity, which LDAP does not provide". >> >> regards, and thanks for removing the deprecation >> >> Justin > > > Would you like to have a go at patching the document?Yes, I''ll propose a patch. Since I have access to OpenLDAP and TDS, and to satisfy my curiosity, could you suggest the type of test I could use for atomicity? I had a look at the free interoperability tests downloadable from the Open Group, but they only included simple uses of modify. regards Justin
Justin Forder wrote:> Francis Cianfrocca wrote: >> >> Would you like to have a go at patching the document? > > Yes, I''ll propose a patch. > > Since I have access to OpenLDAP and TDS, and to satisfy my curiosity, > could you suggest the type of test I could use for atomicity? > > I had a look at the free interoperability tests downloadable from the > Open Group, but they only included simple uses of modify. > > regards > > JustinThanks, looking forward to your documentation patch. You can post it here or email it to me privately. I''m probably going to do another release shortly as I''m adding some LDIF support functions. Atomicity test: try a series of modifies including one or more that violate schema. (For example, if you use inetorgperson, try to delete the SN attribute.) -- Posted via http://www.ruby-forum.com/.
Francis Cianfrocca wrote:> Justin Forder wrote: >> Francis Cianfrocca wrote: >>> Would you like to have a go at patching the document? >> Yes, I''ll propose a patch. >> >> Since I have access to OpenLDAP and TDS, and to satisfy my curiosity, >> could you suggest the type of test I could use for atomicity? >> >> I had a look at the free interoperability tests downloadable from the >> Open Group, but they only included simple uses of modify. >> >> regards >> >> Justin > > Thanks, looking forward to your documentation patch. You can post it > here or email it to me privately. I''m probably going to do another > release shortly as I''m adding some LDIF support functions.I''d like to do some tests before revising the documentation - won''t have access to TDS until Monday. I''ll mail the patch to you privately.> Atomicity test: try a series of modifies including one or more that > violate schema. (For example, if you use inetorgperson, try to delete > the SN attribute.)Thanks - re-reading your current documentation I see that you also mention that trying to add an existing value may cause an error, and I''ve just seen that for myself with the description attribute in groupOfUniqueNames, in OpenLDAP. I wasn''t sure about using schema violation, as the RFC allows schema violation part-way through a group of modification operations, so long as the end result is compliant. I''ll try that out, though... ...yes, OpenLDAP gives me an error when removing the sn from a person, but if I remove it and then add a different value within the same modify, it succeeds. regards Justin