From mortonda at dgrmm.net Wed Mar 4 00:28:38 2009 From: mortonda at dgrmm.net (David Morton) Date: Tue, 03 Mar 2009 23:28:38 -0600 Subject: [Ruby-activeldap-discuss] connection questions Message-ID: <49AE1186.8080005@dgrmm.net> I'm playing with this in a rails console... and seeing some confusing results. I run: >>ActiveLdap::Base.establish_connection(:host=>"stargate",:base=>"dc=example,dc=net",:allow_anonymous=>false, :bind_dn => "cn=People,dc=example,dc=net", :password_block => Proc.new {"wrong password"} ) =>nil At this point, nothing happens, no connection has actually been made. Then I try: >> ActiveLdap::Base.connection.bind When I do this, I see two connection attempts on the LDAP server: Mar 3 23:12:49 stargate slapd[24844]: conn=104 fd=22 ACCEPT from IP=192.168.2.89:63824 (IP=0.0.0.0:389) Mar 3 23:12:49 stargate slapd[24844]: conn=104 op=0 BIND dn="cn=People,dc=example,dc=net" method=128 Mar 3 23:12:49 stargate slapd[24844]: conn=104 op=0 RESULT tag=97 err=49 text= Mar 3 23:12:52 stargate slapd[24844]: conn=105 fd=27 ACCEPT from IP=192.168.2.89:63825 (IP=0.0.0.0:389) Mar 3 23:12:52 stargate slapd[24844]: conn=105 op=0 BIND dn="cn=People,dc=example,dc=net" method=128 Mar 3 23:12:52 stargate slapd[24844]: conn=105 op=0 RESULT tag=97 err=49 text= and I get an exception: ActiveLdap::ConnectionError: Giving up trying to reconnect to LDAP server. The server sees me still connected somehow. I'd like to trap that error more as an AuthenticationError... and I'd like to force a disconnect. I've tried: >> ActiveLdap::Base.connection.unbind => nil which doesn't do any server traffic... If I then try the right password: >>ActiveLdap::Base.establish_connection(:host=>"stargate",:base=>"dc=example,dc=net",:allow_anonymous=>false, :bind_dn => "cn=People,dc=example,dc=net", :password_block => Proc.new {"wrong password"} ) => nil Again, nothing... >> ActiveLdap::Base.connection.bind I get an exception LDAP::Error: already bound. However, on the server side, I see: Mar 3 23:22:38 stargate slapd[24844]: conn=109 fd=29 ACCEPT from IP=192.168.2.89:63838 (IP=0.0.0.0:389) Mar 3 23:22:38 stargate slapd[24844]: conn=109 op=0 BIND dn="cn=People,dc=example,dc=net" method=128 Mar 3 23:22:38 stargate slapd[24844]: conn=109 op=0 BIND dn="cn=People,dc=example,dc=net" mech=SIMPLE ssf=0 Mar 3 23:22:38 stargate slapd[24844]: conn=109 op=0 RESULT tag=97 err=0 text= Which appears to be successful. At this point, this is successful: >> ActiveLdap::Base.connection.unbind => nil Mar 3 23:25:48 stargate slapd[24844]: conn=109 op=1 UNBIND Mar 3 23:25:48 stargate slapd[24844]: conn=109 fd=29 closed All this because I'm trying to debug some connection issues when I'm trying to bind as different users... It seems like sometimes the connection gets hijacked and uses the wrong binding somehow. I've not yet figured it out. More on that later, but does this much look right? It looks buggy to me. From mortonda at dgrmm.net Wed Mar 4 01:23:27 2009 From: mortonda at dgrmm.net (David Morton) Date: Wed, 04 Mar 2009 00:23:27 -0600 Subject: [Ruby-activeldap-discuss] Can't dup NilClass Message-ID: <49AE1E5F.9050801@dgrmm.net> I just tried to update an app from (I think) 1.0.0 to 1.0.2 and I get this when I try to update an entry: TypeError (can't dup NilClass): /lib/active_ldap/attributes.rb:73:in `dup' /lib/active_ldap/attributes.rb:73:in `unnormalize_attribute' /lib/active_ldap/attributes.rb:65:in `each' /lib/active_ldap/attributes.rb:65:in `unnormalize_attribute' /lib/active_ldap/operations.rb:496:in `modify_entry' /lib/active_ldap/operations.rb:495:in `collect' /lib/active_ldap/operations.rb:495:in `modify_entry' /lib/active_ldap/base.rb:1444:in `update_without_callbacks' /lib/active_ldap/base.rb:1418:in `prepare_data_for_saving' /lib/active_ldap/base.rb:1442:in `update_without_callbacks' /vendor/rails/activerecord/lib/active_record/callbacks.rb:240:in `update' /lib/active_ldap/base.rb:1405:in `create_or_update_without_callbacks' /vendor/rails/activerecord/lib/active_record/callbacks.rb:213:in `create_or_update' /lib/active_ldap/base.rb:741:in `save_without_validation' /vendor/rails/activerecord/lib/active_record/validations.rb:934:in `save' /app/controllers/user_controller.rb:181:in `update' From mortonda at dgrmm.net Wed Mar 4 18:11:58 2009 From: mortonda at dgrmm.net (David Morton) Date: Wed, 04 Mar 2009 17:11:58 -0600 Subject: [Ruby-activeldap-discuss] connection questions In-Reply-To: <49AE1186.8080005@dgrmm.net> References: <49AE1186.8080005@dgrmm.net> Message-ID: <49AF0ABE.1010502@dgrmm.net> Following up on my own questions... It appears that ActiveLdap is memory leaking the connection handles and not closing them properly. I'm not sure if this is leading to undetermined behavior later or not, but it's suspicious. All that has to be done is to call establish_connection with a bad password, and bind. If you try to call establish_connection again and bind, the first connection has been leaked, but according to the server the connection is still open. Is there another process that I should be using? In any case, I have a problem with the name of that function. establish_connection does *not* actually establish any connection! From mortonda at dgrmm.net Wed Mar 4 18:31:15 2009 From: mortonda at dgrmm.net (David Morton) Date: Wed, 04 Mar 2009 17:31:15 -0600 Subject: [Ruby-activeldap-discuss] Base.connection returns... ? Message-ID: <49AF0F43.1070706@dgrmm.net> The docs say that Base.connection returns a ActiveLdap::Connection object. But when I run it in irb, I get: ActiveLdap::Adapter::Ldap Where's the connection object? From kou at cozmixng.org Fri Mar 6 23:31:52 2009 From: kou at cozmixng.org (Kouhei Sutou) Date: Sat, 07 Mar 2009 13:31:52 +0900 (JST) Subject: [Ruby-activeldap-discuss] connection questions In-Reply-To: <49AE1186.8080005@dgrmm.net> References: <49AE1186.8080005@dgrmm.net> Message-ID: <20090307.133152.994771096261067663.kou@cozmixng.org> Hi In <49AE1186.8080005 at dgrmm.net> "[Ruby-activeldap-discuss] connection questions" on Tue, 03 Mar 2009 23:28:38 -0600, David Morton wrote: > I'm playing with this in a rails console... and seeing some confusing > results. > > I run: > >>>ActiveLdap::Base.establish_connection(:host=>"stargate",:base=>"dc=example,dc=net",:allow_anonymous=>false, > :bind_dn => "cn=People,dc=example,dc=net", :password_block => Proc.new > {"wrong password"} ) > =>nil > > At this point, nothing happens, no connection has actually been made. It prepares connection configuration. It is the same behavior as ActiveRecord. > Then I try: > >>> ActiveLdap::Base.connection.bind > > > When I do this, I see two connection attempts on the LDAP server: Use ActiveLdap::Base.connection.connect instead. > The server sees me still connected somehow. I'd like to trap that > error more as an AuthenticationError... and I'd like to force a disconnect. Use ActiveLdap::Base.connection.disconnect!. > I've tried: > >>> ActiveLdap::Base.connection.unbind > => nil > > which doesn't do any server traffic... ActiveLdap::Base.connection.unbind does nothing when the connection is not bound. > If I then try the right password: > >>>ActiveLdap::Base.establish_connection(:host=>"stargate",:base=>"dc=example,dc=net",:allow_anonymous=>false, > :bind_dn => "cn=People,dc=example,dc=net", :password_block => Proc.new > {"wrong password"} ) > => nil > > Again, nothing... > >>> ActiveLdap::Base.connection.bind > I get an exception > > LDAP::Error: already bound. Use ActiveLdap::Base.connection.connect instead. > At this point, this is successful: >>> ActiveLdap::Base.connection.unbind > => nil > > Mar 3 23:25:48 stargate slapd[24844]: conn=109 op=1 UNBIND > Mar 3 23:25:48 stargate slapd[24844]: conn=109 fd=29 closed ActiveLdap::Base.connection.unbind does 'unbind' only when the connection is bound. > All this because I'm trying to debug some connection issues when I'm > trying to bind as different users... It seems like sometimes the > connection gets hijacked and uses the wrong binding somehow. I've not > yet figured it out. More on that later, but does this much look right? > It looks buggy to me. Use ActiveLdap::Base#bind for that. The connection is just used for the DN. user = LdapUser.find(dn) begin user.bind # do something rescue ActiveLdap::AuthenticationError, ActiveLdap::LdapError::UnwillingToPerform # error message? end See also: http://code.google.com/p/ruby-activeldap/source/browse/trunk/examples/al-admin/app/models/ldap_user.rb BTW, could you show us a sample code for the problem case what you say? Thanks, -- kou From kou at cozmixng.org Fri Mar 6 23:48:26 2009 From: kou at cozmixng.org (Kouhei Sutou) Date: Sat, 07 Mar 2009 13:48:26 +0900 (JST) Subject: [Ruby-activeldap-discuss] connection questions In-Reply-To: <49AF0ABE.1010502@dgrmm.net> References: <49AE1186.8080005@dgrmm.net> <49AF0ABE.1010502@dgrmm.net> Message-ID: <20090307.134826.1055929314561381493.kou@cozmixng.org> Hi, In <49AF0ABE.1010502 at dgrmm.net> "Re: [Ruby-activeldap-discuss] connection questions" on Wed, 04 Mar 2009 17:11:58 -0600, David Morton wrote: > Following up on my own questions... It appears that ActiveLdap is > memory leaking the connection handles and not closing them properly. > I'm not sure if this is leading to undetermined behavior later or not, > but it's suspicious. > > All that has to be done is to call establish_connection with a bad > password, and bind. If you try to call establish_connection again and > bind, the first connection has been leaked, but according to the server > the connection is still open. Could you show us a (small) code that reproduce the problem? ActiveLdap::Base.establish_connection removes the previous connection before prepares new connection configuration. > Is there another process that I should be using? I can't helps you when I don't know how you write a code for your case. > In any case, I have a problem with the name of that function. > establish_connection does *not* actually establish any connection! The name is imported from ActiveRecord. What name do you prefer? establish_connection doesn't connect to a server because ActiveRecord and ActiveLdap uses lazy connection establishment. It's easy to write our code because we doesn't need to care connection establishment. A connection is established if it's needed. It seems that you are interested in LDAP authentication rather than accessing to LDAP entries. LdapUser.authenticate in examples/al-dmin/app/models/ldap_user.rb will help you for the case. Thanks, -- kou From kou at cozmixng.org Fri Mar 6 23:54:02 2009 From: kou at cozmixng.org (Kouhei Sutou) Date: Sat, 07 Mar 2009 13:54:02 +0900 (JST) Subject: [Ruby-activeldap-discuss] Base.connection returns... ? In-Reply-To: <49AF0F43.1070706@dgrmm.net> References: <49AF0F43.1070706@dgrmm.net> Message-ID: <20090307.135402.468378203425437449.kou@cozmixng.org> Hi, In <49AF0F43.1070706 at dgrmm.net> "[Ruby-activeldap-discuss] Base.connection returns... ?" on Wed, 04 Mar 2009 17:31:15 -0600, David Morton wrote: > The docs say that Base.connection returns a ActiveLdap::Connection > object. But when I run it in irb, I get: > > ActiveLdap::Adapter::Ldap The documents are needed to update but we only have a few human resources. We need people who helps us. > Where's the connection object? ActiveLdap::Adapter::Ldap is also a connection object. There is a LDAP backend (Ruby/LDAP) in the old ActiveLdap but there are three LDAP backends (Ruby/LDAP, Net::LDAP, JNDI) in the current ActiveLdap. This is why ActiveLdap::Adapter::* objects are introduced. It's safe to use public methods defined in ActiveLdap::Adapter::Base because all backends inherit ActiveLdap::Adapter::Base. Thanks, -- kou From kou at cozmixng.org Fri Mar 6 23:55:31 2009 From: kou at cozmixng.org (Kouhei Sutou) Date: Sat, 07 Mar 2009 13:55:31 +0900 (JST) Subject: [Ruby-activeldap-discuss] Can't dup NilClass In-Reply-To: <49AE1E5F.9050801@dgrmm.net> References: <49AE1E5F.9050801@dgrmm.net> Message-ID: <20090307.135531.229420430668659541.kou@cozmixng.org> Hi, In <49AE1E5F.9050801 at dgrmm.net> "[Ruby-activeldap-discuss] Can't dup NilClass" on Wed, 04 Mar 2009 00:23:27 -0600, David Morton wrote: > I just tried to update an app from (I think) 1.0.0 to 1.0.2 and I get > this when I try to update an entry: > > TypeError (can't dup NilClass): > /lib/active_ldap/attributes.rb:73:in `dup' > /lib/active_ldap/attributes.rb:73:in `unnormalize_attribute' > /lib/active_ldap/attributes.rb:65:in `each' > /lib/active_ldap/attributes.rb:65:in `unnormalize_attribute' > /lib/active_ldap/operations.rb:496:in `modify_entry' > /lib/active_ldap/operations.rb:495:in `collect' > /lib/active_ldap/operations.rb:495:in `modify_entry' > /lib/active_ldap/base.rb:1444:in `update_without_callbacks' > /lib/active_ldap/base.rb:1418:in `prepare_data_for_saving' > /lib/active_ldap/base.rb:1442:in `update_without_callbacks' > /vendor/rails/activerecord/lib/active_record/callbacks.rb:240:in > `update' > /lib/active_ldap/base.rb:1405:in `create_or_update_without_callbacks' > /vendor/rails/activerecord/lib/active_record/callbacks.rb:213:in > `create_or_update' > /lib/active_ldap/base.rb:741:in `save_without_validation' > /vendor/rails/activerecord/lib/active_record/validations.rb:934:in > `save' > /app/controllers/user_controller.rb:181:in `update' Could you show us a code (with sample LDAP entry?) that reproduces the problem? Thanks, -- kou From mortonda at dgrmm.net Sat Mar 7 01:32:00 2009 From: mortonda at dgrmm.net (David Morton) Date: Sat, 07 Mar 2009 00:32:00 -0600 Subject: [Ruby-activeldap-discuss] connection questions In-Reply-To: <20090307.134826.1055929314561381493.kou@cozmixng.org> References: <49AE1186.8080005@dgrmm.net> <49AF0ABE.1010502@dgrmm.net> <20090307.134826.1055929314561381493.kou@cozmixng.org> Message-ID: <49B214E0.9060303@dgrmm.net> Kouhei Sutou wrote: >> All that has to be done is to call establish_connection with a bad >> password, and bind. If you try to call establish_connection again and >> bind, the first connection has been leaked, but according to the server >> the connection is still open. >> > > Could you show us a (small) code that reproduce the problem? > ActiveLdap::Base.establish_connection removes the previous > connection before prepares new connection configuration. > I had a small example in my previous email... Just a call to establish_connection, with a bad password. Then call bind. Or call find(). Then fix the password with another call to establish_connection, and then call find() again. The old connection is not closed. Again, bad password: ActiveLdap::Base.establish_connection(:host=>"stargate",:base=>"dc=example,dc=net",:allow_anonymous=>false, :bind_dn => "cn=People,dc=example,dc=net", :password_block => Proc.new {"spa"} ) => nil SentUser.find(:first) I see two ldap connection attempts, both return errors from the server: (note conn=180 and conn=181) Mar 7 00:18:55 stargate slapd[24844]: conn=180 fd=18 ACCEPT from IP=192.168.2.89:57032 (IP=0.0.0.0:389) Mar 7 00:18:55 stargate slapd[24844]: conn=180 op=0 BIND dn="cn=People,dc=example,dc=net" method=128 Mar 7 00:18:55 stargate slapd[24844]: conn=180 op=0 RESULT tag=97 err=49 text= Mar 7 00:18:58 stargate slapd[24844]: conn=181 fd=21 ACCEPT from IP=192.168.2.89:57033 (IP=0.0.0.0:389) Mar 7 00:18:58 stargate slapd[24844]: conn=181 op=0 BIND dn="cn=People,dc=example,dc=net" method=128 Mar 7 00:18:58 stargate slapd[24844]: conn=181 op=0 RESULT tag=97 err=49 text= in irb, I get: ActiveLdap::ConnectionError: Giving up trying to reconnect to LDAP server. Not an authentication error like I expect. Then I call with the right password: ActiveLdap::Base.establish_connection(:host=>"stargate",:base=>"dc=example,dc=net",:allow_anonymous=>false, :bind_dn => "cn=People,dc=example,dc=net", :password_block => Proc.new {"spam"} ) => nil SentUser.find(:first) The server gets a new connection: (note the conn=182) Mar 7 00:19:30 stargate slapd[24844]: conn=182 fd=22 ACCEPT from IP=192.168.2.89:57034 (IP=0.0.0.0:389) Mar 7 00:19:30 stargate slapd[24844]: conn=182 op=0 BIND dn="cn=People,dc=example,dc=net" method=128 Mar 7 00:19:30 stargate slapd[24844]: conn=182 op=0 BIND dn="cn=People,dc=example,dc=net" mech=SIMPLE ssf=0 Mar 7 00:19:30 stargate slapd[24844]: conn=182 op=0 RESULT tag=97 err=0 text= The query works, but what happened to connections 180 and 182? When I close down irb, they close down. Mar 7 00:25:51 stargate slapd[24844]: conn=182 op=4 UNBIND Mar 7 00:25:51 stargate slapd[24844]: conn=182 fd=22 closed Mar 7 00:25:51 stargate slapd[24844]: conn=181 fd=21 closed (connection lost) Mar 7 00:25:51 stargate slapd[24844]: conn=180 fd=18 closed (connection lost) >> In any case, I have a problem with the name of that function. >> establish_connection does *not* actually establish any connection! >> > > The name is imported from ActiveRecord. What name do you > prefer? > That's unfortunate then on the case of active_record. It's more of a set_configuration() type call. > establish_connection doesn't connect to a server because > ActiveRecord and ActiveLdap uses lazy connection > establishment. It's easy to write our code because we > doesn't need to care connection establishment. A connection > is established if it's needed. > > > It seems that you are interested in LDAP authentication > rather than accessing to LDAP entries. LdapUser.authenticate > in examples/al-dmin/app/models/ldap_user.rb will help you > for the case. > A little bit of both, actually. I need to do ldap authentication, but I also need all reads to be as the user - the LDAP server's ACL's take care of a lot of the permissions of what data is visible. So according to the ldap administrator, the proper procedure, (heavy loads may need something different) is to connect, bind as the user, pull whaever data, and disconnect. I guess lazy connecting might be ok, except that it needs to disconnect for the next http call which may or may not be the same user. From mortonda at dgrmm.net Sat Mar 7 01:34:51 2009 From: mortonda at dgrmm.net (David Morton) Date: Sat, 07 Mar 2009 00:34:51 -0600 Subject: [Ruby-activeldap-discuss] Can't dup NilClass In-Reply-To: <20090307.135531.229420430668659541.kou@cozmixng.org> References: <49AE1E5F.9050801@dgrmm.net> <20090307.135531.229420430668659541.kou@cozmixng.org> Message-ID: <49B2158B.3030206@dgrmm.net> Kouhei Sutou wrote: > Hi, > > In <49AE1E5F.9050801 at dgrmm.net> > "[Ruby-activeldap-discuss] Can't dup NilClass" on Wed, 04 Mar 2009 00:23:27 -0600, > David Morton wrote: > > Could you show us a code (with sample LDAP entry?) that > reproduces the problem? > > Unfortunately, part of the schema is private under NDA, so I don't have a smaller working example to show. This was working with 1.0.0, but I get this now with 1.0.2. From kou at cozmixng.org Sat Mar 7 03:01:45 2009 From: kou at cozmixng.org (Kouhei Sutou) Date: Sat, 07 Mar 2009 17:01:45 +0900 (JST) Subject: [Ruby-activeldap-discuss] connection questions In-Reply-To: <49B214E0.9060303@dgrmm.net> References: <49AF0ABE.1010502@dgrmm.net> <20090307.134826.1055929314561381493.kou@cozmixng.org> <49B214E0.9060303@dgrmm.net> Message-ID: <20090307.170145.123339447223498575.kou@cozmixng.org> Hi, In <49B214E0.9060303 at dgrmm.net> "Re: [Ruby-activeldap-discuss] connection questions" on Sat, 07 Mar 2009 00:32:00 -0600, David Morton wrote: > Kouhei Sutou wrote: >>> All that has to be done is to call establish_connection with a bad >>> password, and bind. If you try to call establish_connection again and >>> bind, the first connection has been leaked, but according to the server >>> the connection is still open. >>> >> >> Could you show us a (small) code that reproduce the problem? >> ActiveLdap::Base.establish_connection removes the previous >> connection before prepares new connection configuration. >> > > I had a small example in my previous email... Just a call to > establish_connection, with a bad password. > Then call bind. Or call find(). Then fix the password with another > call to establish_connection, and then call find() again. The old > connection is not closed. I've fixed it in trunk. >>> In any case, I have a problem with the name of that function. >>> establish_connection does *not* actually establish any connection! >>> >> >> The name is imported from ActiveRecord. What name do you >> prefer? >> > > That's unfortunate then on the case of active_record. It's more of a > set_configuration() type call. The name is confused because ActiveLdap keeps n configurations. It's better that set_current_configuration() but I don't like both of them. prepare_connection() or setup_connection() are good for me. >> establish_connection doesn't connect to a server because >> ActiveRecord and ActiveLdap uses lazy connection >> establishment. It's easy to write our code because we >> doesn't need to care connection establishment. A connection >> is established if it's needed. >> >> >> It seems that you are interested in LDAP authentication >> rather than accessing to LDAP entries. LdapUser.authenticate >> in examples/al-dmin/app/models/ldap_user.rb will help you >> for the case. >> > > A little bit of both, actually. I need to do ldap authentication, but I > also need all reads to be as the user - the LDAP server's ACL's take > care of a lot of the permissions of what data is visible. So according > to the ldap administrator, the proper procedure, (heavy loads may need > something different) is to connect, bind as the user, pull whaever data, > and disconnect. > > > I guess lazy connecting might be ok, except that it needs to disconnect > for the next http call which may or may not be the same user. ActiveLdap::Base#bind keeps a connection for each DN. It seems that it's enough for you. LdapUser.find(:all) # search entries permitted for a user in config/ldap.yml user1 = LdapUser.authenticate(...) user1.find(:all) # search entries permitted for user1 Are you saying that "it's not good"? Should we provide ActiveLdap::Base#unbind? You will be able to unbind a connection for the user on each HTTP request. def your_action user = LdapUser.authenticate(:bind_dn => params[:dn], :password => params[:password]) # ... ensure user.unbind if user end Anyway, I can't understand correctly your use case without sample Ruby scripts. Thanks, -- kou From kou at cozmixng.org Sat Mar 7 03:06:02 2009 From: kou at cozmixng.org (Kouhei Sutou) Date: Sat, 07 Mar 2009 17:06:02 +0900 (JST) Subject: [Ruby-activeldap-discuss] Can't dup NilClass In-Reply-To: <49B2158B.3030206@dgrmm.net> References: <49AE1E5F.9050801@dgrmm.net> <20090307.135531.229420430668659541.kou@cozmixng.org> <49B2158B.3030206@dgrmm.net> Message-ID: <20090307.170602.119882392218637314.kou@cozmixng.org> Hi, In <49B2158B.3030206 at dgrmm.net> "Re: [Ruby-activeldap-discuss] Can't dup NilClass" on Sat, 07 Mar 2009 00:34:51 -0600, David Morton wrote: > Kouhei Sutou wrote: >> Hi, >> >> In <49AE1E5F.9050801 at dgrmm.net> >> "[Ruby-activeldap-discuss] Can't dup NilClass" on Wed, 04 Mar 2009 00:23:27 -0600, >> David Morton wrote: >> >> Could you show us a code (with sample LDAP entry?) that >> reproduces the problem? >> >> > > > Unfortunately, part of the schema is private under NDA, so I don't have > a smaller working example to show. This was working with 1.0.0, but I > get this now with 1.0.2. I can't fix a problem without reproducing it on my environment because I can't understand what is a problem... Thanks, -- kou From mortonda at dgrmm.net Sat Mar 7 13:12:30 2009 From: mortonda at dgrmm.net (David Morton) Date: Sat, 07 Mar 2009 12:12:30 -0600 Subject: [Ruby-activeldap-discuss] connection questions In-Reply-To: <20090307.170145.123339447223498575.kou@cozmixng.org> References: <49AF0ABE.1010502@dgrmm.net> <20090307.134826.1055929314561381493.kou@cozmixng.org> <49B214E0.9060303@dgrmm.net> <20090307.170145.123339447223498575.kou@cozmixng.org> Message-ID: <49B2B90E.4010200@dgrmm.net> Kouhei Sutou wrote: >> I had a small example in my previous email... Just a call to >> establish_connection, with a bad password. >> Then call bind. Or call find(). Then fix the password with another >> call to establish_connection, and then call find() again. The old >> connection is not closed. > > I've fixed it in trunk. Ok, so does it reuse that connection when the password is fixed, or does it close the connection? > prepare_connection() or setup_connection() are good for me. I could agree with that, it's much more intuitive. setup_connection, especially if you are calling it multiple times to change the default connection. > ActiveLdap::Base#bind keeps a connection for each DN. It > seems that it's enough for you. > > LdapUser.find(:all) # search entries permitted for a user in config/ldap.yml > > user1 = LdapUser.authenticate(...) > user1.find(:all) # search entries permitted for user1 > > Are you saying that "it's not good"? Should we provide > ActiveLdap::Base#unbind? You will be able to unbind a > connection for the user on each HTTP request. > > def your_action > user = LdapUser.authenticate(:bind_dn => params[:dn], > :password => params[:password]) > # ... > ensure > user.unbind if user > end > > Anyway, I can't understand correctly your use case without > sample Ruby scripts. > I need to authenticate to log into the app, and then every action by that user withing the session needs be be done while bound by that user's dn. I didn't realize that it caches the connection per dn.. but I wonder if that's wise in a long lived program... think of thousands of users that may change their password once a month, we don't want thousands of cached connection sitting around.... Which is why I want to disconnect in an after_filter in every controller action. The other question I have I guess, is while I use an instance of LdapUser to authenticate, I don't use that instance in every controller action throughout the session, I have other ldap classes too. So in the course of a session, a call might need to do: LdapDomain.find(:all) but it needs to be done as the correct user. My understanding then was to use establish_connection and bind within a prefilter for every call to get into the correct user for all ActiveLdap:Base (and derived classes) calls. Then do whatever I need to do as that user, regardless of what class I start with to retreive the information... and then disconnect in a post filter action. In my current, somewhat broken setup, everything works most of the time, but occasionally it starts getting permission errors that seem to be indicative of using the wrong connection. I'm hoping that by forcing a disconnect I can get a better grasp on what's happening. From kou at cozmixng.org Sat Mar 7 21:35:20 2009 From: kou at cozmixng.org (Kouhei Sutou) Date: Sun, 08 Mar 2009 11:35:20 +0900 (JST) Subject: [Ruby-activeldap-discuss] connection questions In-Reply-To: <49B2B90E.4010200@dgrmm.net> References: <49B214E0.9060303@dgrmm.net> <20090307.170145.123339447223498575.kou@cozmixng.org> <49B2B90E.4010200@dgrmm.net> Message-ID: <20090308.113520.295937982770199485.kou@cozmixng.org> Hi, In <49B2B90E.4010200 at dgrmm.net> "Re: [Ruby-activeldap-discuss] connection questions" on Sat, 07 Mar 2009 12:12:30 -0600, David Morton wrote: > Kouhei Sutou wrote: > >>> I had a small example in my previous email... Just a call to >>> establish_connection, with a bad password. >>> Then call bind. Or call find(). Then fix the password with another >>> call to establish_connection, and then call find() again. The old >>> connection is not closed. >> >> I've fixed it in trunk. > > Ok, so does it reuse that connection when the password is fixed, or does > it close the connection? Yes. >> prepare_connection() or setup_connection() are good for me. > > I could agree with that, it's much more intuitive. setup_connection, > especially if you are calling it multiple times to change the default > connection. I've changed established_connection() to setup_connection(). establish_connection() is deprecated since 1.1.0. >> Anyway, I can't understand correctly your use case without >> sample Ruby scripts. >> > > I need to authenticate to log into the app, and then every action by > that user withing the session needs be be done while bound by that > user's dn. I understood it. > I didn't realize that it caches the connection per dn.. but I wonder if > that's wise in a long lived program... think of thousands of users that > may change their password once a month, we don't want thousands of > cached connection sitting around.... We may need timeout for caching. (Or LDAP server will disconnect a connection that doesn't communicate for a long time.) > The other question I have I guess, is while I use an instance of > LdapUser to authenticate, I don't use that instance in every controller > action throughout the session, I have other ldap classes too. So in the > course of a session, a call might need to do: > > LdapDomain.find(:all) A cached connection for a DN is propagated implicitly. class LdapUser < ActiveLdap::Base belongs_to :groups, :many => 'memberUid' end user = LdapUser.find(dn) user.groups # [LdapGroup, ...] # They have the same connection as user. Or you can pass a connection explicitly. LdapDomain.find(:all, :connection => user.connection) If we know your sample scripts, we may give you more correct advise. > but it needs to be done as the correct user. My understanding then was > to use establish_connection and bind within a prefilter for every call > to get into the correct user for all ActiveLdap:Base (and derived > classes) calls. Then do whatever I need to do as that user, regardless > of what class I start with to retreive the information... and then > disconnect in a post filter action. In AL-Admin, it doesn't need to bind for each HTTP request. It uses cached a connection per DN. > In my current, somewhat broken setup, everything works most of the time, > but occasionally it starts getting permission errors that seem to be > indicative of using the wrong connection. I'm hoping that by forcing a > disconnect I can get a better grasp on what's happening. We can't consider better API unless a use case for the problem with sample scripts. Thanks, -- kou From raikomitsu at gmail.com Tue Mar 10 15:29:51 2009 From: raikomitsu at gmail.com (Raiko) Date: Tue, 10 Mar 2009 14:29:51 -0500 Subject: [Ruby-activeldap-discuss] Active Directory attributes In-Reply-To: <6d01c96d0903101115k5b94e5c5nc65b877b3c1de02f@mail.gmail.com> References: <6d01c96d0903101115k5b94e5c5nc65b877b3c1de02f@mail.gmail.com> Message-ID: <6d01c96d0903101229v538954ecj8cdbceeff37e75cf@mail.gmail.com> (Sorry if double post.. I wasn't confirmed to send the original mail. If you don't see the original mail, disregard this notice.) Hello, How can I make sAMAccountName able to be one of the dn_attributes? If I try to use it that way, it fails. If I set it to cn, it works, but I don't see sAMAccountName returned in the list of attributes. A find does work when I do :attribute => "sAMAccountName", so I know activeldap can see that attribute. Any suggestions? -------------- next part -------------- An HTML attachment was scrubbed... URL: From kou at cozmixng.org Thu Mar 12 07:57:40 2009 From: kou at cozmixng.org (Kouhei Sutou) Date: Thu, 12 Mar 2009 20:57:40 +0900 (JST) Subject: [Ruby-activeldap-discuss] Active Directory attributes In-Reply-To: <6d01c96d0903101229v538954ecj8cdbceeff37e75cf@mail.gmail.com> References: <6d01c96d0903101115k5b94e5c5nc65b877b3c1de02f@mail.gmail.com> <6d01c96d0903101229v538954ecj8cdbceeff37e75cf@mail.gmail.com> Message-ID: <20090312.205740.145758949453814372.kou@cozmixng.org> Hi, In <6d01c96d0903101229v538954ecj8cdbceeff37e75cf at mail.gmail.com> "[Ruby-activeldap-discuss] Active Directory attributes" on Tue, 10 Mar 2009 14:29:51 -0500, Raiko wrote: > How can I make sAMAccountName able to be one of the dn_attributes? If I try to > use it that way, it fails. If I set it to cn, it works, but I don't see > sAMAccountName returned in the list of attributes. > > A find does work when I do :attribute => "sAMAccountName", so I know activeldap > can see that attribute. > > Any suggestions? Do your entry have a securityPrincipal objectClass? Thanks, -- kou From raikomitsu at gmail.com Thu Mar 12 16:09:19 2009 From: raikomitsu at gmail.com (Raiko Mitsu) Date: Thu, 12 Mar 2009 15:09:19 -0500 Subject: [Ruby-activeldap-discuss] Active Directory attributes In-Reply-To: <20090312.205740.145758949453814372.kou@cozmixng.org> References: <6d01c96d0903101115k5b94e5c5nc65b877b3c1de02f@mail.gmail.com> <6d01c96d0903101229v538954ecj8cdbceeff37e75cf@mail.gmail.com> <20090312.205740.145758949453814372.kou@cozmixng.org> Message-ID: <006201c9a34e$6f63fc50$4e2bf4f0$@com> Hello, I added that to my class list, but that caused all searches to fail. -----Original Message----- From: ruby-activeldap-discuss-bounces at rubyforge.org [mailto:ruby-activeldap-discuss-bounces at rubyforge.org] On Behalf Of Kouhei Sutou Sent: Thursday, March 12, 2009 6:58 AM To: ruby-activeldap-discuss at rubyforge.org Subject: Re: [Ruby-activeldap-discuss] Active Directory attributes Hi, In <6d01c96d0903101229v538954ecj8cdbceeff37e75cf at mail.gmail.com> "[Ruby-activeldap-discuss] Active Directory attributes" on Tue, 10 Mar 2009 14:29:51 -0500, Raiko wrote: > How can I make sAMAccountName able to be one of the dn_attributes? If I try to > use it that way, it fails. If I set it to cn, it works, but I don't see > sAMAccountName returned in the list of attributes. > > A find does work when I do :attribute => "sAMAccountName", so I know activeldap > can see that attribute. > > Any suggestions? Do your entry have a securityPrincipal objectClass? Thanks, -- kou _______________________________________________ Ruby-activeldap-discuss mailing list Ruby-activeldap-discuss at rubyforge.org http://rubyforge.org/mailman/listinfo/ruby-activeldap-discuss From kou at cozmixng.org Thu Mar 12 22:43:59 2009 From: kou at cozmixng.org (Kouhei Sutou) Date: Fri, 13 Mar 2009 11:43:59 +0900 Subject: [Ruby-activeldap-discuss] Active Directory attributes In-Reply-To: <006201c9a34e$6f63fc50$4e2bf4f0$@com> References: <6d01c96d0903101115k5b94e5c5nc65b877b3c1de02f@mail.gmail.com> <6d01c96d0903101229v538954ecj8cdbceeff37e75cf@mail.gmail.com> <20090312.205740.145758949453814372.kou@cozmixng.org> <006201c9a34e$6f63fc50$4e2bf4f0$@com> Message-ID: Hi, 2009/3/13 Raiko Mitsu : > I added that to my class list, but that caused all searches to fail. Thanks for trying it. I've fixed it in trunk. Could you try trunk? http://code.google.com/p/ruby-activeldap/wiki/UsingTrunkWithRails Thanks, -- kou From raikomitsu at gmail.com Mon Mar 16 10:47:39 2009 From: raikomitsu at gmail.com (Raiko Mitsu) Date: Mon, 16 Mar 2009 09:47:39 -0500 Subject: [Ruby-activeldap-discuss] Active Directory attributes In-Reply-To: References: <6d01c96d0903101115k5b94e5c5nc65b877b3c1de02f@mail.gmail.com> <6d01c96d0903101229v538954ecj8cdbceeff37e75cf@mail.gmail.com> <20090312.205740.145758949453814372.kou@cozmixng.org> <006201c9a34e$6f63fc50$4e2bf4f0$@com> Message-ID: <002501c9a646$28e9c3e0$7abd4ba0$@com> Hello, Sorry to be so late getting back to you. Busy week and weekend! I tried trunk this morning. The searches still fail when securityPrincipal is in the class list, but now it doesn't complain when I put sAMAccountName in as the dn attribute. -----Original Message----- From: ruby-activeldap-discuss-bounces at rubyforge.org [mailto:ruby-activeldap-discuss-bounces at rubyforge.org] On Behalf Of Kouhei Sutou Sent: Thursday, March 12, 2009 9:44 PM To: ruby-activeldap-discuss at rubyforge.org Subject: Re: [Ruby-activeldap-discuss] Active Directory attributes Hi, 2009/3/13 Raiko Mitsu : > I added that to my class list, but that caused all searches to fail. Thanks for trying it. I've fixed it in trunk. Could you try trunk? http://code.google.com/p/ruby-activeldap/wiki/UsingTrunkWithRails Thanks, -- kou _______________________________________________ Ruby-activeldap-discuss mailing list Ruby-activeldap-discuss at rubyforge.org http://rubyforge.org/mailman/listinfo/ruby-activeldap-discuss From raikomitsu at gmail.com Mon Mar 16 10:52:11 2009 From: raikomitsu at gmail.com (Raiko Mitsu) Date: Mon, 16 Mar 2009 09:52:11 -0500 Subject: [Ruby-activeldap-discuss] Active Directory attributes In-Reply-To: References: <6d01c96d0903101115k5b94e5c5nc65b877b3c1de02f@mail.gmail.com> <6d01c96d0903101229v538954ecj8cdbceeff37e75cf@mail.gmail.com> <20090312.205740.145758949453814372.kou@cozmixng.org> <006201c9a34e$6f63fc50$4e2bf4f0$@com> Message-ID: <002601c9a646$cadde0f0$6099a2d0$@com> Hello again, I meant to also mention that the searches do not fail if you leave securityPrinicpal out of the class list and set the dn attribute to sAMAccountName. Is that the expected functionality? -----Original Message----- From: ruby-activeldap-discuss-bounces at rubyforge.org [mailto:ruby-activeldap-discuss-bounces at rubyforge.org] On Behalf Of Kouhei Sutou Sent: Thursday, March 12, 2009 9:44 PM To: ruby-activeldap-discuss at rubyforge.org Subject: Re: [Ruby-activeldap-discuss] Active Directory attributes Hi, 2009/3/13 Raiko Mitsu : > I added that to my class list, but that caused all searches to fail. Thanks for trying it. I've fixed it in trunk. Could you try trunk? http://code.google.com/p/ruby-activeldap/wiki/UsingTrunkWithRails Thanks, -- kou _______________________________________________ Ruby-activeldap-discuss mailing list Ruby-activeldap-discuss at rubyforge.org http://rubyforge.org/mailman/listinfo/ruby-activeldap-discuss From mortonda at dgrmm.net Mon Mar 16 16:11:15 2009 From: mortonda at dgrmm.net (David Morton) Date: Mon, 16 Mar 2009 15:11:15 -0500 Subject: [Ruby-activeldap-discuss] Can't dup NilClass In-Reply-To: <20090307.170602.119882392218637314.kou@cozmixng.org> References: <49AE1E5F.9050801@dgrmm.net> <20090307.135531.229420430668659541.kou@cozmixng.org> <49B2158B.3030206@dgrmm.net> <20090307.170602.119882392218637314.kou@cozmixng.org> Message-ID: <49BEB263.1060209@dgrmm.net> Kouhei Sutou wrote: >>> Could you show us a code (with sample LDAP entry?) that >>> reproduces the problem? Maybe this will get on the right track. Using a basic User class: class User < ActiveLdap::Base ldap_mapping :dn_attribute => 'uid', :prefix => 'ou=Clients', :classes => ['top', 'account', 'posixAccount'] end a=User.find :first puts a.to_ldif version: 1 dn: uid=joe,ou=Clients,dc=example,dc=com cn: Joe description: foo gidNumber: 1 homeDirectory: /home/joe objectClass: account objectClass: posixAccount objectClass: top uid: joe uidNumber: 3 => nil then simulate data coming in from the web page: params = {"description"=>[""]} a.attributes=params a.save And that's when I get the error. Admittedly, I should probably strip the empty fields from the array, as I really only want something like: ["one","two"] and not ["one","two",""] but the issue also hits when a multiple value field has only no entries, [""]. Maybe I'm not merging in the data from the web page correctly, but I used to do it that way. But when an item comes in blank, it errors. If that's not the right way to apply parameters to an object, what is? From mortonda at dgrmm.net Mon Mar 16 22:06:57 2009 From: mortonda at dgrmm.net (David Morton) Date: Mon, 16 Mar 2009 21:06:57 -0500 Subject: [Ruby-activeldap-discuss] a better attributes= Message-ID: <49BF05C1.1050003@dgrmm.net> I alluded in a previous message that I used attributes= to mass assign the values from a web form to the ldap object. I see from the documentation that "Also be sure to only pass in key-value pairs of your choosing. Do not let URL/form hackers supply the keys. " I thought this was the active record convention in rails... But in ActiveLdap, it also bypasses any overridden accessors. So what is the proper way to do this? The only other method I've come up with is something like: params['user'].each do |attr,value| next if attr == 'uid' if @domain.respond_to?(attr) if value.respond_to?("-") value -= [""] end end @user.send("#{attr}=",value) end What I think should happen is have a set_attributes() action that behaves like attributes= does right now, and have attributes= work sort of like the above code... it should loop through the hash, call the attribute accessor method (even if overridden in the model) which would automatically block unknown key values, as there would be no method defined. In that piece of code above... I had a few quirks that I have questions about. I had to skip the attribute that distinguishes the dn, otherwise it would give me a no such object error. ie, if the dn is uid=joe,dc=example,dc=com - I had to skip the uid object. Obviously you shouldn't change it anyway, but I don;t know if I'm missing something important. Then I had to remove any empty elements from arrays, else it would give an error about nil objects... From kou at cozmixng.org Tue Mar 17 08:28:04 2009 From: kou at cozmixng.org (Kouhei Sutou) Date: Tue, 17 Mar 2009 21:28:04 +0900 (JST) Subject: [Ruby-activeldap-discuss] Active Directory attributes In-Reply-To: <002601c9a646$cadde0f0$6099a2d0$@com> References: <006201c9a34e$6f63fc50$4e2bf4f0$@com> <002601c9a646$cadde0f0$6099a2d0$@com> Message-ID: <20090317.212804.4959786895397910.kou@cozmixng.org> Hi, In <002601c9a646$cadde0f0$6099a2d0$@com> "Re: [Ruby-activeldap-discuss] Active Directory attributes" on Mon, 16 Mar 2009 09:52:11 -0500, "Raiko Mitsu" wrote: > I meant to also mention that the searches do not fail if you leave > securityPrinicpal out of the class list and set the dn attribute to > sAMAccountName. Is that the expected functionality? Yes. Your original code will work well without any changes. Thanks, -- kou From kou at cozmixng.org Tue Mar 17 08:48:24 2009 From: kou at cozmixng.org (Kouhei Sutou) Date: Tue, 17 Mar 2009 21:48:24 +0900 (JST) Subject: [Ruby-activeldap-discuss] Can't dup NilClass In-Reply-To: <49BEB263.1060209@dgrmm.net> References: <49B2158B.3030206@dgrmm.net> <20090307.170602.119882392218637314.kou@cozmixng.org> <49BEB263.1060209@dgrmm.net> Message-ID: <20090317.214824.999284356098975215.kou@cozmixng.org> Hi, In <49BEB263.1060209 at dgrmm.net> "Re: [Ruby-activeldap-discuss] Can't dup NilClass" on Mon, 16 Mar 2009 15:11:15 -0500, David Morton wrote: >>>> Could you show us a code (with sample LDAP entry?) that >>>> reproduces the problem? > > > Maybe this will get on the right track. Thanks for the additional information. I've fixed it in trunk. Thanks, -- kou From kou at cozmixng.org Tue Mar 17 08:51:37 2009 From: kou at cozmixng.org (Kouhei Sutou) Date: Tue, 17 Mar 2009 21:51:37 +0900 (JST) Subject: [Ruby-activeldap-discuss] a better attributes= In-Reply-To: <49BF05C1.1050003@dgrmm.net> References: <49BF05C1.1050003@dgrmm.net> Message-ID: <20090317.215137.506212773266927709.kou@cozmixng.org> Hi, In <49BF05C1.1050003 at dgrmm.net> "[Ruby-activeldap-discuss] a better attributes=" on Mon, 16 Mar 2009 21:06:57 -0500, David Morton wrote: > I alluded in a previous message that I used attributes= to mass assign > the values from a web form to the ldap object. I see from the > documentation that "Also be sure to only pass in key-value pairs of your > choosing. Do not let URL/form hackers supply the keys. " > > I thought this was the active record convention in rails... Yes. attributes= is the right way. The documentation is outdated... > In that piece of code above... I had a few quirks that I have questions > about. I had to skip the attribute that distinguishes the dn, > otherwise it would give me a no such object error. ie, if the dn is > uid=joe,dc=example,dc=com - I had to skip the uid object. Obviously you > shouldn't change it anyway, but I don;t know if I'm missing something > important. The DN attributes are removed from mass assignment targets implicitly. Thanks, -- kou From mortonda at dgrmm.net Tue Mar 17 13:20:14 2009 From: mortonda at dgrmm.net (David Morton) Date: Tue, 17 Mar 2009 12:20:14 -0500 Subject: [Ruby-activeldap-discuss] a better attributes= In-Reply-To: <20090317.215137.506212773266927709.kou@cozmixng.org> References: <49BF05C1.1050003@dgrmm.net> <20090317.215137.506212773266927709.kou@cozmixng.org> Message-ID: <49BFDBCE.3000806@dgrmm.net> Kouhei Sutou wrote: >> I thought this was the active record convention in rails... > > Yes. attributes= is the right way. > The documentation is outdated... Ok, one of these days I might try to submit a doc patch. lol. One other thing, I think the docs on http://ruby-activeldap.rubyforge.org/doc/ are for 1.0.2 From mortonda at dgrmm.net Tue Mar 17 13:29:36 2009 From: mortonda at dgrmm.net (David Morton) Date: Tue, 17 Mar 2009 12:29:36 -0500 Subject: [Ruby-activeldap-discuss] oops, version confusion Message-ID: <49BFDE00.7070802@dgrmm.net> hah, nevermind on the doc question, I thought we were at 1.0.3, but I see that 1.0.2 is most recent. Time to brew some more coffee. From mortonda at dgrmm.net Tue Mar 17 14:24:45 2009 From: mortonda at dgrmm.net (David Morton) Date: Tue, 17 Mar 2009 13:24:45 -0500 Subject: [Ruby-activeldap-discuss] another attributes= bug Message-ID: <49BFEAED.2070604@dgrmm.net> This one took a while to narrow down. It involves attribute aliases and accessor overrides. given a person: class Person < ActiveLdap::Base ldap_mapping :dn_attribute => 'cn', :prefix => 'ou=Clients', :classes => ['top', 'person'] def surname=(description) set_attribute(:surname, description.collect { |item| item.upcase }) end end puts p.to_ldif version: 1 dn: cn=david,ou=Clients,dc=example,dc=com cn: david objectClass: person objectClass: top sn: MORTON => nil Now, surname is an alias for sn in the core schema I believe. params = {"surname"=>"smith"} p.attributes=params at this point, the sn attribute is lowercase, not uppercase like it should be. print p.to_ldif version: 1 dn: cn=david,ou=Clients,dc=sentinare,dc=net cn: david objectClass: person objectClass: top sn: smith From dieter at dkluenter.de Tue Mar 17 15:09:29 2009 From: dieter at dkluenter.de (Dieter Kluenter) Date: Tue, 17 Mar 2009 20:09:29 +0100 Subject: [Ruby-activeldap-discuss] another attributes= bug In-Reply-To: <49BFEAED.2070604@dgrmm.net> (David Morton's message of "Tue, 17 Mar 2009 13:24:45 -0500") References: <49BFEAED.2070604@dgrmm.net> Message-ID: <873adcj79y.fsf@rubin.l4b.de> David Morton writes: > This one took a while to narrow down. It involves attribute aliases and > accessor overrides. > > given a person: > > class Person < ActiveLdap::Base > ldap_mapping :dn_attribute => 'cn', :prefix => 'ou=Clients', > :classes => ['top', 'person'] > > def surname=(description) > set_attribute(:surname, description.collect { |item| item.upcase }) > end > end > > puts p.to_ldif > version: 1 > dn: cn=david,ou=Clients,dc=example,dc=com > cn: david > objectClass: person > objectClass: top > sn: MORTON > => nil > > > Now, surname is an alias for sn in the core schema I believe. > > params = {"surname"=>"smith"} > > p.attributes=params > > > at this point, the sn attribute is lowercase, not uppercase like it > should be. > > > print p.to_ldif > version: 1 > dn: cn=david,ou=Clients,dc=sentinare,dc=net > cn: david > objectClass: person > objectClass: top > sn: smith RFC 4517, CN and SN and most attribute types syntax is caseIgnoreMatch, respectively caseIgnoreIA5Match. -Dieter -- Dieter Kl?nter | Systemberatung http://www.dpunkt.de/buecher/2104.html sip: +49.180.1555.7770535 GPG Key ID:8EF7B6C6 53?08'09,95"N 10?08'02,42"E From mortonda at dgrmm.net Tue Mar 17 16:02:31 2009 From: mortonda at dgrmm.net (David Morton) Date: Tue, 17 Mar 2009 15:02:31 -0500 Subject: [Ruby-activeldap-discuss] another attributes= bug In-Reply-To: <873adcj79y.fsf@rubin.l4b.de> References: <49BFEAED.2070604@dgrmm.net> <873adcj79y.fsf@rubin.l4b.de> Message-ID: <49C001D7.30507@dgrmm.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dieter Kluenter wrote: > RFC 4517, CN and SN and most attribute types syntax is > caseIgnoreMatch, respectively caseIgnoreIA5Match. > > -Dieter That's beside the point in this example. My point is that the attribute accessor is not being called. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknAAdQACgkQUy30ODPkzl3k4wCeIOn9vuFP3IfsLdBS+GDUiUM5 0tcAnj2H4Hok6bsXcCFDwSblsGGF881s =TC+A -----END PGP SIGNATURE----- From NICHOLR3 at uk.ibm.com Wed Mar 18 09:42:47 2009 From: NICHOLR3 at uk.ibm.com (Richard 3 Nicholas) Date: Wed, 18 Mar 2009 13:42:47 +0000 Subject: [Ruby-activeldap-discuss] Activeldap 1.0.2 incompatible with Rails 2.3.2 when ActiveRecord not in use for the rails app. In-Reply-To: <49BFEAED.2070604@dgrmm.net> Message-ID: What I did. Downloaded rails 2.3.2 and all dependencies. Created a new application: rails rntestapp Edited config\environment.rb and added these lines: config.frameworks -= [ :active_record ] config.gem "activeldap", :lib => "active_ldap" The server comes up with either one of these two lines present in environment.rb but fails when they are both present.... C:\rails\rntestapp>ruby script/server => Booting Mongrel => Rails 2.3.2 application starting on http://0.0.0.0:3000 c:/ruby/lib/ruby/gems/1.8/gems/activesupport-2.3.2/lib/active_support/dependencies.rb:440:in `load_missing_constant': uninitialized constant ActiveRecord::Validations (NameError) from c:/ruby/lib/ruby/gems/1.8/gems/activesupport-2.3.2/lib/active_support/dependencies.rb:80:in `const_missing' from c:/ruby/lib/ruby/gems/1.8/gems/activerecord-2.3.2/lib/active_record/base.rb:3139 from c:/ruby/lib/ruby/gems/1.8/gems/activerecord-2.3.2/lib/active_record/base.rb:3137:in `class_eval' from c:/ruby/lib/ruby/gems/1.8/gems/activerecord-2.3.2/lib/active_record/base.rb:3137 from c:/ruby/lib/ruby/gems/1.8/gems/activerecord-2.3.2/lib/active_record/validations.rb:9 from c:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require' from c:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `require' from c:/ruby/lib/ruby/gems/1.8/gems/activesupport-2.3.2/lib/active_support/dependencies.rb:156:in `require' ... 27 levels... from c:/ruby/lib/ruby/gems/1.8/gems/rails-2.3.2/lib/commands/server.rb:84 from c:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require' from c:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `require' from script/server:3 Richard Nicholas Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From kou at cozmixng.org Wed Mar 18 10:01:57 2009 From: kou at cozmixng.org (Kouhei Sutou) Date: Wed, 18 Mar 2009 23:01:57 +0900 (JST) Subject: [Ruby-activeldap-discuss] another attributes= bug In-Reply-To: <49BFEAED.2070604@dgrmm.net> References: <49BFEAED.2070604@dgrmm.net> Message-ID: <20090318.230157.849557997894694080.kou@cozmixng.org> Hi, In <49BFEAED.2070604 at dgrmm.net> "[Ruby-activeldap-discuss] another attributes= bug" on Tue, 17 Mar 2009 13:24:45 -0500, David Morton wrote: > This one took a while to narrow down. It involves attribute aliases and > accessor overrides. > > given a person: > > class Person < ActiveLdap::Base > ldap_mapping :dn_attribute => 'cn', :prefix => 'ou=Clients', > :classes => ['top', 'person'] > > def surname=(description) > set_attribute(:surname, description.collect { |item| item.upcase }) > end > end You need to use the main attribute name which is the first NAME value. The sn attribute is defined on my environment like the following: attributetype ( 2.5.4.4 NAME ( 'sn' 'surname' ) DESC 'RFC2256: last (family) name(s) for which the entity is known by' SUP name ) In the case, 'sn' is the main attribute name for '2.5.4.4' attribute type. Other names are alias names ('surname') of the main attribute name ('sn'). So, use the following definition: > def sn=(description) > set_attribute(:sn, description.collect { |item| item.upcase }) > end Thanks, -- kou From kou at cozmixng.org Wed Mar 18 10:03:00 2009 From: kou at cozmixng.org (Kouhei Sutou) Date: Wed, 18 Mar 2009 23:03:00 +0900 (JST) Subject: [Ruby-activeldap-discuss] Activeldap 1.0.2 incompatible with Rails 2.3.2 when ActiveRecord not in use for the rails app. In-Reply-To: References: <49BFEAED.2070604@dgrmm.net> Message-ID: <20090318.230300.680961627163916909.kou@cozmixng.org> Hi, In "[Ruby-activeldap-discuss] Activeldap 1.0.2 incompatible with Rails 2.3.2 when ActiveRecord not in use for the rails app." on Wed, 18 Mar 2009 13:42:47 +0000, Richard 3 Nicholas wrote: > What I did. Downloaded rails 2.3.2 and all dependencies. Created a new > application: > > rails rntestapp > > Edited config\environment.rb and added these lines: > > config.frameworks -= [ :active_record ] > config.gem "activeldap", :lib => "active_ldap" > > The server comes up with either one of these two lines present in > environment.rb but fails when they are both present.... ActiveLdap 1.0.2 doesn't support Rails 2.3.2 because ActiveLdap 1.0.2 was released before Rails 2.3.2 release. Rails 2.3.2 is supported in trunk. Thanks, -- kou From mortonda at dgrmm.net Wed Mar 18 10:07:11 2009 From: mortonda at dgrmm.net (David Morton) Date: Wed, 18 Mar 2009 09:07:11 -0500 Subject: [Ruby-activeldap-discuss] Activeldap 1.0.2 incompatible with Rails 2.3.2 when ActiveRecord not in use for the rails app. In-Reply-To: References: Message-ID: <49C1000F.3000003@dgrmm.net> Richard 3 Nicholas wrote: > > What I did. Downloaded rails 2.3.2 and all dependencies. Created a new > application: > > rails rntestapp > > Edited config\environment.rb and added these lines: > > config.frameworks -= [ :active_record ] > config.gem "activeldap", :lib => "active_ldap" IIRC, ActiveLdap uses some of the ActiveRecord framework for Validations code... From mortonda at dgrmm.net Wed Mar 18 10:11:56 2009 From: mortonda at dgrmm.net (David Morton) Date: Wed, 18 Mar 2009 09:11:56 -0500 Subject: [Ruby-activeldap-discuss] another attributes= bug In-Reply-To: <20090318.230157.849557997894694080.kou@cozmixng.org> References: <49BFEAED.2070604@dgrmm.net> <20090318.230157.849557997894694080.kou@cozmixng.org> Message-ID: <49C1012C.8090100@dgrmm.net> Kouhei Sutou wrote: > > You need to use the main attribute name which is the first > NAME value. The sn attribute is defined on my environment > like the following: Yes, I know that works, but if the form tries to send back the alias name, attributes= will happily add the value without calling the correct accessor, which could end up with incorrect data. It either needs to figure out the right function to call, or throw an error... Otherwise a form hacker could introduce an uncontrolled value. From NICHOLR3 at uk.ibm.com Wed Mar 18 11:06:09 2009 From: NICHOLR3 at uk.ibm.com (Richard 3 Nicholas) Date: Wed, 18 Mar 2009 15:06:09 +0000 Subject: [Ruby-activeldap-discuss] Activeldap 1.0.2 incompatible with Rails 2.3.2 when ActiveRecord not in use for the rails app. In-Reply-To: <20090318.230300.680961627163916909.kou@cozmixng.org> Message-ID: Thanks, I'll get it from trunk. thought as much. Richard Nicholas Kouhei Sutou Sent by: ruby-activeldap-discuss-bounces at rubyforge.org 18/03/2009 14:03 Please respond to ruby-activeldap-discuss at rubyforge.org To ruby-activeldap-discuss at rubyforge.org cc Subject Re: [Ruby-activeldap-discuss] Activeldap 1.0.2 incompatible with Rails 2.3.2 when ActiveRecord not in use for the rails app. Hi, In "[Ruby-activeldap-discuss] Activeldap 1.0.2 incompatible with Rails 2.3.2 when ActiveRecord not in use for the rails app." on Wed, 18 Mar 2009 13:42:47 +0000, Richard 3 Nicholas wrote: > What I did. Downloaded rails 2.3.2 and all dependencies. Created a new > application: > > rails rntestapp > > Edited config\environment.rb and added these lines: > > config.frameworks -= [ :active_record ] > config.gem "activeldap", :lib => "active_ldap" > > The server comes up with either one of these two lines present in > environment.rb but fails when they are both present.... ActiveLdap 1.0.2 doesn't support Rails 2.3.2 because ActiveLdap 1.0.2 was released before Rails 2.3.2 release. Rails 2.3.2 is supported in trunk. Thanks, -- kou _______________________________________________ Ruby-activeldap-discuss mailing list Ruby-activeldap-discuss at rubyforge.org http://rubyforge.org/mailman/listinfo/ruby-activeldap-discuss Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From mortonda at dgrmm.net Wed Mar 18 11:30:50 2009 From: mortonda at dgrmm.net (David Morton) Date: Wed, 18 Mar 2009 10:30:50 -0500 Subject: [Ruby-activeldap-discuss] Can't dup NilClass In-Reply-To: <20090317.214824.999284356098975215.kou@cozmixng.org> References: <49B2158B.3030206@dgrmm.net> <20090307.170602.119882392218637314.kou@cozmixng.org> <49BEB263.1060209@dgrmm.net> <20090317.214824.999284356098975215.kou@cozmixng.org> Message-ID: <49C113AA.5050201@dgrmm.net> Kouhei Sutou wrote: > Hi, > > In <49BEB263.1060209 at dgrmm.net> > "Re: [Ruby-activeldap-discuss] Can't dup NilClass" on Mon, 16 Mar 2009 15:11:15 -0500, > David Morton wrote: > >>>>> Could you show us a code (with sample LDAP entry?) that >>>>> reproduces the problem? >> >> Maybe this will get on the right track. > > Thanks for the additional information. > > I've fixed it in trunk. I downloaded trunk and merged it into my rails project... I still get the error for: params = {"description"=>["one","two",""]} user.attributes=params and looking at the code, I don't see how that if self.class.blank_value?(value) actually blocks the replace with an empty value... is something else needed for a non-binary attribute? From mortonda at dgrmm.net Wed Mar 18 12:14:48 2009 From: mortonda at dgrmm.net (David Morton) Date: Wed, 18 Mar 2009 11:14:48 -0500 Subject: [Ruby-activeldap-discuss] Can't dup NilClass In-Reply-To: <49C113AA.5050201@dgrmm.net> References: <49B2158B.3030206@dgrmm.net> <20090307.170602.119882392218637314.kou@cozmixng.org> <49BEB263.1060209@dgrmm.net> <20090317.214824.999284356098975215.kou@cozmixng.org> <49C113AA.5050201@dgrmm.net> Message-ID: <49C11DF8.7090601@dgrmm.net> David Morton wrote: > I still get the error for: The solution that works for me is to add this: value -= [nil] right before both attributes.push calls. @@ -1402,6 +1402,7 @@ module ActiveLdap # Ditched delete then replace because attribs with no equality # match rules will fails end + value -= [nil] attributes.push([:replace, k, value]) end data.each do |k, v| @@ -1411,6 +1412,7 @@ module ActiveLdap # Detect subtypes and account for them # REPLACE will function like ADD, but doesn't hit EQUALITY problems # TODO: Added equality(attr) to Schema + value -= [nil] attributes.push([:replace, k, value]) end From kou at cozmixng.org Sat Mar 21 21:43:32 2009 From: kou at cozmixng.org (Kouhei Sutou) Date: Sun, 22 Mar 2009 10:43:32 +0900 (JST) Subject: [Ruby-activeldap-discuss] another attributes= bug In-Reply-To: <49C1012C.8090100@dgrmm.net> References: <49BFEAED.2070604@dgrmm.net> <20090318.230157.849557997894694080.kou@cozmixng.org> <49C1012C.8090100@dgrmm.net> Message-ID: <20090322.104332.321689433999135210.kou@cozmixng.org> Hi, In <49C1012C.8090100 at dgrmm.net> "Re: [Ruby-activeldap-discuss] another attributes= bug" on Wed, 18 Mar 2009 09:11:56 -0500, David Morton wrote: >> You need to use the main attribute name which is the first >> NAME value. The sn attribute is defined on my environment >> like the following: > > Yes, I know that works, but if the form tries to send back the alias > name, attributes= will happily add the value without calling the correct > accessor, which could end up with incorrect data. It either needs to > figure out the right function to call, or throw an error... > > Otherwise a form hacker could introduce an uncontrolled value. I understand. I'll consider about it. Maybe, we should normalize attribute name in mass assignments. Thanks, -- kou From kou at cozmixng.org Sat Mar 21 22:06:37 2009 From: kou at cozmixng.org (Kouhei Sutou) Date: Sun, 22 Mar 2009 11:06:37 +0900 (JST) Subject: [Ruby-activeldap-discuss] Can't dup NilClass In-Reply-To: <49C113AA.5050201@dgrmm.net> References: <49BEB263.1060209@dgrmm.net> <20090317.214824.999284356098975215.kou@cozmixng.org> <49C113AA.5050201@dgrmm.net> Message-ID: <20090322.110637.1076064300636356027.kou@cozmixng.org> Hi, In <49C113AA.5050201 at dgrmm.net> "Re: [Ruby-activeldap-discuss] Can't dup NilClass" on Wed, 18 Mar 2009 10:30:50 -0500, David Morton wrote: > I downloaded trunk and merged it into my rails project... > > I still get the error for: > > params = {"description"=>["one","two",""]} > > user.attributes=params Thanks for the report. I've (maybe, really) fixed it in trunk. > and looking at the code, I don't see how that > > if self.class.blank_value?(value) > > actually blocks the replace with an empty value... is something else > needed for a non-binary attribute? It isn't needed for a non-binary attribute. It's the reason why the code exists that we always use "replace" modify operation for adding, deleting and replacing attributes. We need to set empty value for replaced value when we want to add a new value with "replace" operation. We can use a normal empty value for a non-binary attribute but need to use a binary empty value for a binary attribute. It's {"binary" => []}. Thanks, -- kou From mortonda at dgrmm.net Sun Mar 22 00:15:58 2009 From: mortonda at dgrmm.net (David Morton) Date: Sat, 21 Mar 2009 23:15:58 -0500 Subject: [Ruby-activeldap-discuss] another attributes= bug In-Reply-To: <20090322.104332.321689433999135210.kou@cozmixng.org> References: <49BFEAED.2070604@dgrmm.net> <20090318.230157.849557997894694080.kou@cozmixng.org> <49C1012C.8090100@dgrmm.net> <20090322.104332.321689433999135210.kou@cozmixng.org> Message-ID: <1973A8A7-2053-482F-8FC9-CF51FAF9F2CA@dgrmm.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 21, 2009, at 8:43 PM, Kouhei Sutou wrote: >> >> >> accessor, which could end up with incorrect data. It either needs to >> figure out the right function to call, or throw an error... >> >> Otherwise a form hacker could introduce an uncontrolled value. > > I understand. I'll consider about it. > Maybe, we should normalize attribute name in mass assignments. Yeah after thinking about it, I see that it isn't an easy problem to fix - you'd have to read my mind to know which variation of the alias I'm overriding. :) David Morton Maia Mailguard http://www.maiamailguard.com mortonda at dgrmm.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFJxbt+Uy30ODPkzl0RAltRAJ0aML5SpJkEcH3q/OwsSIic8vQvtQCgnm4O ljz+9NlVR6ZxIhKzi2DArik= =2CxZ -----END PGP SIGNATURE----- From alexey.chebotar at gmail.com Thu Mar 26 11:56:00 2009 From: alexey.chebotar at gmail.com (Alexey Chebotar) Date: Thu, 26 Mar 2009 17:56:00 +0200 Subject: [activeldap-discuss] [ANN] Ruby/LDAP 0.9.8 Message-ID: <49CBA590.1050305@gmail.com> Hello. New version of ruby-ldap has been released. Ruby LDAP has new maintainer. I'm Alexey Chebotar, and I will maintain Ruby/LDAP as long as I can. More info in ActiveLdap project wiki: http://code.google.com/p/ruby-activeldap/wiki/RubyLDAP 0.9.7 -> 0.9.8: * Supported Ruby 1.9.x. Thanks to everyone who helped me. -- Alexey Chebotar