All, does anyone use the Oasis DSML standard? It''s a mapping between standard LDAP/LDIF operations and data structures to XML. There are some Java tools that handle DSML. I just saw a requirement for accessing an LDAP server by a service that requires results encoded in DSML, so I thought I''d better add this support to the Net::LDAP library. Is this of interest to any of you? Interesting enough that you''d be willing to help beta-test it :-)? (cross-posted on the Ruby list) -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
Francis Cianfrocca wrote:> All, > > does anyone use the Oasis DSML standard? It''s a mapping between standard > LDAP/LDIF operations and data structures to XML. There are some Java > tools that handle DSML. I just saw a requirement for accessing an LDAP > server by a service that requires results encoded in DSML, so I thought > I''d better add this support to the Net::LDAP library. > > Is this of interest to any of you? Interesting enough that you''d be > willing to help beta-test it :-)?Hi Francis That seems like a lot of work, and when I looked I had the impression that there wasn''t much activity around DSML. (If you take a look at the email archives here: http://lists.oasis-open.org/archives/dsml/ you won''t see any actual discussion later than April 2003) If you are extending Net::LDAP, it would be good to have the ability to add LDAP controls to bind requests and operation requests, as well as to be able to handle controls associated with responses. This appears to be a standard extension mechanism for LDAP, and it is supported by JNDI. I think Net::LDAP has some capability for handling controls associated with responses, but I can''t see any facility for adding controls to binds and operation requests. Some administrative operations on IBM''s Tivoli Directory Server require the use of an "administrative control" in the bind and the operation request. The specific example I am aware of is that TDS can be configured to lock a user out after a number of consecutive failed logins. The locked-out status is represented by a couple of operational attributes on the user entry, and can be reset by deleting those attributes. The deletion is only permitted when both the bind and the modification request carry the IBM-defined administrative control. This is something that we can do with JNDI, but would not be able to do with Net::LDAP. regards Justin P.S. With respect to our earlier discussion, my own tests on OpenLDAP show that it respects the ordering and atomicity requirements for multiple modification operations in an LDAP modify command. When I started doing similar tests on TDS I ran into a problem, and haven''t had time yet to try again. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
Justin Forder wrote: > Some administrative operations on IBM''s Tivoli Directory Server require> the use of an "administrative control" in the bind and the operation > request. The specific example I am aware of is that TDS can be > configured to lock a user out after a number of consecutive failed > logins. The locked-out status is represented by a couple of operational > attributes on the user entry, and can be reset by deleting those > attributes. The deletion is only permitted when both the bind and the > modification request carry the IBM-defined administrative control. > > This is something that we can do with JNDI, but would not be able to do > with Net::LDAP. >If Net::LDAP had this ability, would you be able to test it easily? Re DSML: I''ve never felt like it was terribly worth doing for exactly the reason you gave, however it does seem to come up here and there in situations that are commercially interesting. -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
Francis Cianfrocca wrote:> Justin Forder wrote: > > Some administrative operations on IBM''s Tivoli Directory Server > require >> the use of an "administrative control" in the bind and the operation >> request. The specific example I am aware of is that TDS can be >> configured to lock a user out after a number of consecutive failed >> logins. The locked-out status is represented by a couple of operational >> attributes on the user entry, and can be reset by deleting those >> attributes. The deletion is only permitted when both the bind and the >> modification request carry the IBM-defined administrative control. >> >> This is something that we can do with JNDI, but would not be able to do >> with Net::LDAP. >> > If Net::LDAP had this ability, would you be able to test it easily?I''d only be able to test it in limited ways, e.g. in the scenario outlined above. In your position I think I would want to look at the requests and responses on the wire and compare them both with the spec and with a reference implementation. (We ended up looking at the source code for IBM''s command-line tools to be sure of what was happening when the option for this administrative control was used).> Re DSML: I''ve never felt like it was terribly worth doing for exactly > the reason you gave, however it does seem to come up here and there in > situations that are commercially interesting.Fine! Justin --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
Justin Forder wrote: > I''d only be able to test it in limited ways, e.g. in the scenario> outlined above. In your position I think I would want to look at the > requests and responses on the wire and compare them both with the spec > and with a reference implementation.That''s fine. We''ll definitely test against the wire protocol and against openldap, that''s normal procedure. What was more interesting to me is getting a case like yours that amounts to a beta test. -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---