My favorites | Sign in
Project Logo
                
Details: Show all Hide all

Last 30 days

  • Dec 18, 2009
    issue 38 (Ruby-LDAP controls missing for #search_ext and #search_ext2) changed by Alexey.Chebotar   -   Hi rubymage! Thanks for the patch. I had pushed it in Git: http://github.com/alexey-chebotar/ruby- ldap/commit/5d7c49b36ae9bec7a45c530f42258cb1ac2cf367 P.S. I hope that Michael Granger it is you. (please let me know if it is not)
    Status: Fixed
    Owner: Alexey.Chebotar
    Hi rubymage! Thanks for the patch. I had pushed it in Git: http://github.com/alexey-chebotar/ruby- ldap/commit/5d7c49b36ae9bec7a45c530f42258cb1ac2cf367 P.S. I hope that Michael Granger it is you. (please let me know if it is not)
    Status: Fixed
    Owner: Alexey.Chebotar
  • Dec 18, 2009
    issue 36 (Binding with username and password fails) commented on by koutou   -   Really? 1.2.1 will be fixed it. Please try again.
    Really? 1.2.1 will be fixed it. Please try again.
  • Dec 18, 2009
    issue 30 (Intermittent SSL Errors Closing the LDAP Connection) commented on by koutou   -   Try to use net-ldap 0.0.5.
    Try to use net-ldap 0.0.5.
  • Dec 18, 2009
    r1122 (* Fixed a bug that setting 'false' but 'nil' is returned. ...) committed by koutou   -   * Fixed a bug that setting 'false' but 'nil' is returned. Reported by Hideyuki Yasuda. Thanks!!!
    * Fixed a bug that setting 'false' but 'nil' is returned. Reported by Hideyuki Yasuda. Thanks!!!
  • Dec 16, 2009
    issue 37 (Does not work with rails 2.3.5.) Status changed by koutou   -   Thanks for your notification. I've fixed it in trunk.
    Status: Fixed
    Thanks for your notification. I've fixed it in trunk.
    Status: Fixed
  • Dec 16, 2009
    r1121 (* adad zachwily to thanks list. Thanks!!! ) committed by koutou   -   * adad zachwily to thanks list. Thanks!!!
    * adad zachwily to thanks list. Thanks!!!
  • Dec 16, 2009
    r1120 (* [#37] Fixed gem dependencies in Rakefile. Reported by za...) committed by koutou   -   * [#37] Fixed gem dependencies in Rakefile. Reported by zachwily. Thanks!!!
    * [#37] Fixed gem dependencies in Rakefile. Reported by zachwily. Thanks!!!
  • Dec 15, 2009
    issue 37 (Does not work with rails 2.3.5.) commented on by zachwily   -   The dependencies in the Rakefile need to be changed from 2.3.4, so the gem gets built with the right deps. I manually changed the deps in the gemspec after installing and it worked.
    The dependencies in the Rakefile need to be changed from 2.3.4, so the gem gets built with the right deps. I manually changed the deps in the gemspec after installing and it worked.
  • Dec 15, 2009
    r1119 (* 1.2.1 -> 1.2.2. ) committed by koutou   -   * 1.2.1 -> 1.2.2.
    * 1.2.1 -> 1.2.2.
  • Dec 15, 2009
    r1118 (New release tag) committed by koutou   -   New release tag
    New release tag
  • Dec 15, 2009
    r1117 (* 1.2.1 will be released at 2009/12/15. ) committed by koutou   -   * 1.2.1 will be released at 2009/12/15.
    * 1.2.1 will be released at 2009/12/15.
  • Dec 13, 2009
    r1116 (* Supported GetText 2.1.0 and Locale 2.0.5. ) committed by koutou   -   * Supported GetText 2.1.0 and Locale 2.0.5.
    * Supported GetText 2.1.0 and Locale 2.0.5.
  • Dec 13, 2009
    r1115 (* Supported ActiveRecord 2.3.5 and Rails 2.3.5. ) committed by koutou   -   * Supported ActiveRecord 2.3.5 and Rails 2.3.5.
    * Supported ActiveRecord 2.3.5 and Rails 2.3.5.
  • Dec 13, 2009
    r1114 (* add a test for modifying an entry with nested options. ) committed by koutou   -   * add a test for modifying an entry with nested options.
    * add a test for modifying an entry with nested options.
  • Dec 13, 2009
    r1113 (* add a test for adding an entry with nested options. ) committed by koutou   -   * add a test for adding an entry with nested options.
    * add a test for adding an entry with nested options.
  • Dec 13, 2009
    r1112 (* cleanup. ) committed by koutou   -   * cleanup.
    * cleanup.
  • Dec 13, 2009
    r1111 (* support nested attribute options. ) committed by koutou   -   * support nested attribute options.
    * support nested attribute options.
  • Dec 11, 2009
    issue 38 (Ruby-LDAP controls missing for #search_ext and #search_ext2) reported by rubymage   -   What steps will reproduce the problem? 1. Query the directory using either #search_ext or #search_ext2 with a server control (e.g., the paged results control) 2. Fetch the results, and try to fetch the controls coming back from the server for the estimated count and pager cookie What is the expected output? What do you see instead? I expected the #controls method to return the server control for paged results. It was empty. What version of the product are you using? On what operating system? I'm using the 0.9.9 gem on MacOS X 10.5 and 10.6, FreeBSD 6.x, 7.x, and 8.x, and Ubuntu Linux. Please provide any additional information below. I'm not sure if this is the right place to file a bug report, but since this is where the download and repository are, I though this would be the best place to try. I'd be happy to move it elsewhere if there's somewhere more appropriate. I've attached a patch that fixes this issue (ruby-ldap-248.patch) and a patch to the paged-result example (example/pr_ctl) that demonstrates the problem.
    What steps will reproduce the problem? 1. Query the directory using either #search_ext or #search_ext2 with a server control (e.g., the paged results control) 2. Fetch the results, and try to fetch the controls coming back from the server for the estimated count and pager cookie What is the expected output? What do you see instead? I expected the #controls method to return the server control for paged results. It was empty. What version of the product are you using? On what operating system? I'm using the 0.9.9 gem on MacOS X 10.5 and 10.6, FreeBSD 6.x, 7.x, and 8.x, and Ubuntu Linux. Please provide any additional information below. I'm not sure if this is the right place to file a bug report, but since this is where the download and repository are, I though this would be the best place to try. I'd be happy to move it elsewhere if there's somewhere more appropriate. I've attached a patch that fixes this issue (ruby-ldap-248.patch) and a patch to the paged-result example (example/pr_ctl) that demonstrates the problem.
  • Dec 10, 2009
    issue 37 (Does not work with rails 2.3.5.) reported by aepstein607   -   What steps will reproduce the problem? 1. Start a rails project (rails project && cd project) 2. Add config.gem 'active_ldap' to env/config.rb 3. script/console What is the expected output? What do you see instead? I expect console to start. Instead I get an error like: "can't activate activesupport (= 2.3.4, runtime) for [], already activated activesupport-2.3.5 for ["rails-2.3.5"] (Gem::LoadError) ... from...active_ldap.rb:899 What version of the product are you using? On what operating system? Latest: active_ldap-1.2.0 Please provide any additional information below. The call should be for a version >= 2.3.4, not precisely 2.3.4. Apparent workaround is to use rails 2.3.4 until the bug is fixed in active_ldap.
    What steps will reproduce the problem? 1. Start a rails project (rails project && cd project) 2. Add config.gem 'active_ldap' to env/config.rb 3. script/console What is the expected output? What do you see instead? I expect console to start. Instead I get an error like: "can't activate activesupport (= 2.3.4, runtime) for [], already activated activesupport-2.3.5 for ["rails-2.3.5"] (Gem::LoadError) ... from...active_ldap.rb:899 What version of the product are you using? On what operating system? Latest: active_ldap-1.2.0 Please provide any additional information below. The call should be for a version >= 2.3.4, not precisely 2.3.4. Apparent workaround is to use rails 2.3.4 until the bug is fixed in active_ldap.

Earlier this year

  • Nov 26, 2009
    issue 35 (Can't build an org chart using ActiveLdap 1.2.0) commented on by pedzsan   -   Wow golly... I spent half of yesterday and half of today trying to get a "manager" relationship to work and was going nuts. I finally chainsawed the code to get it working. Was going to post a patch or ask a question and bumped into this... I kept assuming that something this basic can't be broken for long without an update. Maybe a new level should be pushed out. Thanks!
    Wow golly... I spent half of yesterday and half of today trying to get a "manager" relationship to work and was going nuts. I finally chainsawed the code to get it working. Was going to post a patch or ask a question and bumped into this... I kept assuming that something this basic can't be broken for long without an update. Maybe a new level should be pushed out. Thanks!
  • Nov 24, 2009
    issue 36 (Binding with username and password fails) reported by andy.goldstein   -   What steps will reproduce the problem? 1. Try to bind to an LDAP server using a username and password What is the expected output? What do you see instead? Expect the bind to succeed. Instead, get this exception (net-ldap) NoMethodError (undefined method `to_ber' for #<ActiveLdap::DistinguishedName:0x67b0bfb2>): /Users/andy/torquebox/jruby/lib/ruby/gems/1.8/gems/net-ldap- 0.0.5/lib/net/ldap.rb:1295:in `bind_simple' /Users/andy/torquebox/jruby/lib/ruby/gems/1.8/gems/net-ldap- 0.0.5/lib/net/ldap.rb:1270:in `bind' activeldap (1.2.0) lib/active_ldap/adapter/net_ldap.rb:135:in `execute' activeldap (1.2.0) lib/active_ldap/adapter/base.rb:654:in `log' activeldap (1.2.0) lib/active_ldap/adapter/base.rb:654:in `log' activeldap (1.2.0) lib/active_ldap/adapter/net_ldap.rb:135:in `execute' activeldap (1.2.0) lib/active_ldap/adapter/net_ldap.rb:269:in `simple_bind' activeldap (1.2.0) lib/active_ldap/adapter/base.rb:368:in `simple_bind' activeldap (1.2.0) lib/active_ldap/adapter/net_ldap.rb:263:in `simple_bind' activeldap (1.2.0) lib/active_ldap/adapter/base.rb:85:in `bind' activeldap (1.2.0) lib/active_ldap/adapter/net_ldap.rb:52:in `bind' activeldap (1.2.0) lib/active_ldap/adapter/base.rb:53:in `connect' activeldap (1.2.0) lib/active_ldap/adapter/net_ldap.rb:24:in `connect' activeldap (1.2.0) lib/active_ldap/base.rb:1014:in `bind' Or this exception (JRuby) NativeException (java.lang.ClassCastException: org.jruby.RubyObject cannot be cast to java.lang.String): com/sun/jndi/ldap/LdapCtx.java:2624:in `connect' com/sun/jndi/ldap/LdapCtx.java:2602:in `ensureOpen' com/sun/jndi/ldap/LdapCtx.java:2576:in `ensureOpen' com/sun/jndi/ldap/LdapCtx.java:2572:in `reconnect' javax/naming/ldap/InitialLdapContext.java:173:in `reconnect' activeldap (1.2.0) lib/active_ldap/adapter/jndi_connection.rb:164:in `setup_context' activeldap (1.2.0) lib/active_ldap/adapter/jndi_connection.rb:99:in `simple_bind' activeldap (1.2.0) lib/active_ldap/adapter/jndi.rb:88:in `execute' activeldap (1.2.0) lib/active_ldap/adapter/base.rb:654:in `log' activeldap (1.2.0) lib/active_ldap/adapter/base.rb:654:in `log' activeldap (1.2.0) lib/active_ldap/adapter/jndi.rb:88:in `execute' activeldap (1.2.0) lib/active_ldap/adapter/jndi.rb:147:in `simple_bind' activeldap (1.2.0) lib/active_ldap/adapter/base.rb:368:in `simple_bind' activeldap (1.2.0) lib/active_ldap/adapter/jndi.rb:145:in `simple_bind' activeldap (1.2.0) lib/active_ldap/adapter/base.rb:85:in `bind' activeldap (1.2.0) lib/active_ldap/adapter/base.rb:53:in `connect' activeldap (1.2.0) lib/active_ldap/adapter/jndi.rb:22:in `connect' activeldap (1.2.0) lib/active_ldap/base.rb:1014:in `bind' What version of the product are you using? On what operating system? 1.2.0, 1.2.1 (svn trunk) on Mac OS X Snow Leopard Please provide any additional information below. I have been able to fix this by editing line 1007 in lib/active_ldap/base.rb. It currently reads config = {:bind_dn => dn, :allow_anonymous => false}.merge(config) I changed it so dn (which is an instance of ActiveLdap::DistinguishedName) is converted to a String: config = {:bind_dn => dn.to_s, :allow_anonymous => false}.merge(config)
    What steps will reproduce the problem? 1. Try to bind to an LDAP server using a username and password What is the expected output? What do you see instead? Expect the bind to succeed. Instead, get this exception (net-ldap) NoMethodError (undefined method `to_ber' for #<ActiveLdap::DistinguishedName:0x67b0bfb2>): /Users/andy/torquebox/jruby/lib/ruby/gems/1.8/gems/net-ldap- 0.0.5/lib/net/ldap.rb:1295:in `bind_simple' /Users/andy/torquebox/jruby/lib/ruby/gems/1.8/gems/net-ldap- 0.0.5/lib/net/ldap.rb:1270:in `bind' activeldap (1.2.0) lib/active_ldap/adapter/net_ldap.rb:135:in `execute' activeldap (1.2.0) lib/active_ldap/adapter/base.rb:654:in `log' activeldap (1.2.0) lib/active_ldap/adapter/base.rb:654:in `log' activeldap (1.2.0) lib/active_ldap/adapter/net_ldap.rb:135:in `execute' activeldap (1.2.0) lib/active_ldap/adapter/net_ldap.rb:269:in `simple_bind' activeldap (1.2.0) lib/active_ldap/adapter/base.rb:368:in `simple_bind' activeldap (1.2.0) lib/active_ldap/adapter/net_ldap.rb:263:in `simple_bind' activeldap (1.2.0) lib/active_ldap/adapter/base.rb:85:in `bind' activeldap (1.2.0) lib/active_ldap/adapter/net_ldap.rb:52:in `bind' activeldap (1.2.0) lib/active_ldap/adapter/base.rb:53:in `connect' activeldap (1.2.0) lib/active_ldap/adapter/net_ldap.rb:24:in `connect' activeldap (1.2.0) lib/active_ldap/base.rb:1014:in `bind' Or this exception (JRuby) NativeException (java.lang.ClassCastException: org.jruby.RubyObject cannot be cast to java.lang.String): com/sun/jndi/ldap/LdapCtx.java:2624:in `connect' com/sun/jndi/ldap/LdapCtx.java:2602:in `ensureOpen' com/sun/jndi/ldap/LdapCtx.java:2576:in `ensureOpen' com/sun/jndi/ldap/LdapCtx.java:2572:in `reconnect' javax/naming/ldap/InitialLdapContext.java:173:in `reconnect' activeldap (1.2.0) lib/active_ldap/adapter/jndi_connection.rb:164:in `setup_context' activeldap (1.2.0) lib/active_ldap/adapter/jndi_connection.rb:99:in `simple_bind' activeldap (1.2.0) lib/active_ldap/adapter/jndi.rb:88:in `execute' activeldap (1.2.0) lib/active_ldap/adapter/base.rb:654:in `log' activeldap (1.2.0) lib/active_ldap/adapter/base.rb:654:in `log' activeldap (1.2.0) lib/active_ldap/adapter/jndi.rb:88:in `execute' activeldap (1.2.0) lib/active_ldap/adapter/jndi.rb:147:in `simple_bind' activeldap (1.2.0) lib/active_ldap/adapter/base.rb:368:in `simple_bind' activeldap (1.2.0) lib/active_ldap/adapter/jndi.rb:145:in `simple_bind' activeldap (1.2.0) lib/active_ldap/adapter/base.rb:85:in `bind' activeldap (1.2.0) lib/active_ldap/adapter/base.rb:53:in `connect' activeldap (1.2.0) lib/active_ldap/adapter/jndi.rb:22:in `connect' activeldap (1.2.0) lib/active_ldap/base.rb:1014:in `bind' What version of the product are you using? On what operating system? 1.2.0, 1.2.1 (svn trunk) on Mac OS X Snow Leopard Please provide any additional information below. I have been able to fix this by editing line 1007 in lib/active_ldap/base.rb. It currently reads config = {:bind_dn => dn, :allow_anonymous => false}.merge(config) I changed it so dn (which is an instance of ActiveLdap::DistinguishedName) is converted to a String: config = {:bind_dn => dn.to_s, :allow_anonymous => false}.merge(config)
  • Nov 24, 2009
    issue 30 (Intermittent SSL Errors Closing the LDAP Connection) commented on by patrick.klingemann   -   /usr/lib/ruby/1.8/openssl/buffering.rb:178:in `syswrite' /usr/lib/ruby/1.8/openssl/buffering.rb:178:in `do_write' /usr/lib/ruby/1.8/openssl/buffering.rb:192:in `write' /usr/lib/ruby/gems/1.8/gems/ruby-net-ldap-0.0.4/lib/net/ldap.rb:1167:in `search' /usr/lib/ruby/gems/1.8/gems/ruby-net-ldap-0.0.4/lib/net/ldap.rb:1144:in `loop' /usr/lib/ruby/gems/1.8/gems/ruby-net-ldap-0.0.4/lib/net/ldap.rb:1144:in `search' /usr/lib/ruby/gems/1.8/gems/activeldap-1.2.0/lib/active_ldap/adapter/net_ldap.rb:135:in `send' /usr/lib/ruby/gems/1.8/gems/activeldap-1.2.0/lib/active_ldap/adapter/net_ldap.rb:135:in `execute' /usr/lib/ruby/gems/1.8/gems/activeldap-1.2.0/lib/active_ldap/adapter/base.rb:654:in `log' [RAILS_ROOT]/vendor/rails/activesupport/lib/active_support/core_ext/benchmark.rb:10:in `realtime' /usr/lib/ruby/gems/1.8/gems/activeldap-1.2.0/lib/active_ldap/adapter/base.rb:654:in `log' /usr/lib/ruby/gems/1.8/gems/activeldap-1.2.0/lib/active_ldap/adapter/net_ldap.rb:135:in `execute' /usr/lib/ruby/gems/1.8/gems/activeldap-1.2.0/lib/active_ldap/adapter/net_ldap.rb:78:in `search' /usr/lib/ruby/gems/1.8/gems/activeldap-1.2.0/lib/active_ldap/adapter/base.rb:169:in `search' /usr/lib/ruby/gems/1.8/gems/activeldap-1.2.0/lib/active_ldap/adapter/base.rb:270:in `operation' /usr/lib/ruby/gems/1.8/gems/activeldap-1.2.0/lib/active_ldap/timeout.rb:15:in `call' /usr/lib/ruby/gems/1.8/gems/activeldap-1.2.0/lib/active_ldap/timeout.rb:15:in `alarm' /usr/lib/ruby/gems/1.8/gems/activeldap-1.2.0/lib/active_ldap/adapter/base.rb:316:in `with_timeout' /usr/lib/ruby/gems/1.8/gems/activeldap-1.2.0/lib/active_ldap/adapter/base.rb:269:in `operation' /usr/lib/ruby/gems/1.8/gems/activeldap-1.2.0/lib/active_ldap/adapter/base.rb:168:in `search' /usr/lib/ruby/gems/1.8/gems/activeldap-1.2.0/lib/active_ldap/adapter/net_ldap.rb:66:in `search' /usr/lib/ruby/gems/1.8/gems/activeldap-1.2.0/lib/active_ldap/operations.rb:65:in `search' /usr/lib/ruby/gems/1.8/gems/activeldap-1.2.0/lib/active_ldap/operations.rb:279:in `find_every' /usr/lib/ruby/gems/1.8/gems/activeldap-1.2.0/lib/active_ldap/operations.rb:252:in `find_initial' /usr/lib/ruby/gems/1.8/gems/activeldap-1.2.0/lib/active_ldap/operations.rb:217:in `find' [RAILS_ROOT]/app/models/user.rb:13:in `authldap_user' [RAILS_ROOT]/app/models/user.rb:45:in `email' [RAILS_ROOT]/vendor/rails/activerecord/lib/active_record/serializers/xml_serializer.rb:340:in `send' [RAILS_ROOT]/vendor/rails/activerecord/lib/active_record/serializers/xml_serializer.rb:340:in `compute_value' [RAILS_ROOT]/vendor/rails/activerecord/lib/active_record/serializers/xml_serializer.rb:287:in `initialize' [RAILS_ROOT]/vendor/rails/activerecord/lib/active_record/serializers/xml_serializer.rb:199:in `new' [RAILS_ROOT]/vendor/rails/activerecord/lib/active_record/serializers/xml_serializer.rb:199:in `serializable_attributes' [RAILS_ROOT]/vendor/rails/activerecord/lib/active_record/serializers/xml_serializer.rb:199:in `collect' [RAILS_ROOT]/vendor/rails/activerecord/lib/active_record/serializers/xml_serializer.rb:199:in `serializable_attributes' [RAILS_ROOT]/vendor/rails/activerecord/lib/active_record/serializers/xml_serializer.rb:210:in `add_attributes' [RAILS_ROOT]/vendor/rails/activerecord/lib/active_record/serializers/xml_serializer.rb:271:in `serialize' [RAILS_ROOT]/vendor/rails/activesupport/lib/active_support/vendor/builder-2.1.2/builder/xmlbase.rb:134:in `call' [RAILS_ROOT]/vendor/rails/activesupport/lib/active_support/vendor/builder-2.1.2/builder/xmlbase.rb:134:in `_nested_structures' [RAILS_ROOT]/vendor/rails/activesupport/lib/active_support/vendor/builder-2.1.2/builder/xmlbase.rb:58:in `method_missing' [RAILS_ROOT]/vendor/rails/activesupport/lib/active_support/vendor/builder-2.1.2/builder/xmlbase.rb:31:in `tag!' [RAILS_ROOT]/vendor/rails/activerecord/lib/active_record/serializers/xml_serializer.rb:270:in `serialize' [RAILS_ROOT]/vendor/rails/activerecord/lib/active_record/serialization.rb:94:in `to_s' [RAILS_ROOT]/vendor/rails/activerecord/lib/active_record/serializers/xml_serializer.rb:156:in `to_xml' [RAILS_ROOT]/vendor/rails/activesupport/lib/active_support/core_ext/array/conversions.rb:189:in `to_xml' [RAILS_ROOT]/vendor/rails/activesupport/lib/active_support/core_ext/array/conversions.rb:189:in `each' [RAILS_ROOT]/vendor/rails/activesupport/lib/active_support/core_ext/array/conversions.rb:189:in `to_xml' [RAILS_ROOT]/vendor/rails/activesupport/lib/active_support/vendor/builder-2.1.2/builder/xmlbase.rb:134:in `call' [RAILS_ROOT]/vendor/rails/activesupport/lib/active_support/vendor/builder-2.1.2/builder/xmlbase.rb:134:in `_nested_structures' [RAILS_ROOT]/vendor/rails/activesupport/lib/active_support/vendor/builder-2.1.2/builder/xmlbase.rb:58:in `method_missing' [RAILS_ROOT]/vendor/rails/activesupport/lib/active_support/vendor/builder-2.1.2/builder/xmlbase.rb:31:in `tag!' [RAILS_ROOT]/vendor/rails/activesupport/lib/active_support/core_ext/array/conversions.rb:187:in `to_xml' [RAILS_ROOT]/vendor/rails/actionpack/lib/action_controller/base.rb:955:in `render_without_benchmark' [RAILS_ROOT]/vendor/rails/actionpack/lib/action_controller/benchmarking.rb:51:in `render_without_active_scaffold' [RAILS_ROOT]/vendor/rails/activesupport/lib/active_support/core_ext/benchmark.rb:17:in `ms' [RAILS_ROOT]/vendor/rails/activesupport/lib/active_support/core_ext/benchmark.rb:10:in `realtime' [RAILS_ROOT]/vendor/rails/activesupport/lib/active_support/core_ext/benchmark.rb:17:in `ms' [RAILS_ROOT]/vendor/rails/actionpack/lib/action_controller/benchmarking.rb:51:in `render_without_active_scaffold' [RAILS_ROOT]/vendor/plugins/active_scaffold/lib/extensions/action_controller_rendering.rb:13:in `render' [RAILS_ROOT]/app/controllers/rest/users_controller.rb:10:in `index' [RAILS_ROOT]/vendor/rails/actionpack/lib/action_controller/mime_responds.rb:135:in `call' [RAILS_ROOT]/vendor/rails/actionpack/lib/action_controller/mime_responds.rb:135:in `custom' [RAILS_ROOT]/vendor/rails/actionpack/lib/action_controller/mime_responds.rb:179:in `call' [RAILS_ROOT]/vendor/rails/actionpack/lib/action_controller/mime_responds.rb:179:in `respond' [RAILS_ROOT]/vendor/rails/actionpack/lib/action_controller/mime_responds.rb:173:in `each' [RAILS_ROOT]/vendor/rails/actionpack/lib/action_controller/mime_responds.rb:173:in `respond' [RAILS_ROOT]/vendor/rails/actionpack/lib/action_controller/mime_responds.rb:107:in `respond_to' [RAILS_ROOT]/app/controllers/rest/users_controller.rb:9:in `index' [RAILS_ROOT]/vendor/rails/actionpack/lib/action_controller/base.rb:1331:in `send' [RAILS_ROOT]/vendor/rails/actionpack/lib/action_controller/base.rb:1331:in `perform_action_without_filters' [RAILS_ROOT]/vendor/rails/actionpack/lib/action_controller/filters.rb:617:in `call_filters' [RAILS_ROOT]/vendor/rails/actionpack/lib/action_controller/filters.rb:610:in `perform_action_without_benchmark' [RAILS_ROOT]/vendor/rails/actionpack/lib/action_controller/benchmarking.rb:68:in `perform_action_without_rescue' [RAILS_ROOT]/vendor/rails/activesupport/lib/active_support/core_ext/benchmark.rb:17:in `ms' [RAILS_ROOT]/vendor/rails/activesupport/lib/active_support/core_ext/benchmark.rb:10:in `realtime' [RAILS_ROOT]/vendor/rails/activesupport/lib/active_support/core_ext/benchmark.rb:17:in `ms' [RAILS_ROOT]/vendor/rails/actionpack/lib/action_controller/benchmarking.rb:68:in `perform_action_without_rescue' [RAILS_ROOT]/vendor/rails/actionpack/lib/action_controller/rescue.rb:160:in `perform_action_without_flash' [RAILS_ROOT]/vendor/rails/actionpack/lib/action_controller/flash.rb:146:in `perform_action' [RAILS_ROOT]/vendor/rails/actionpack/lib/action_controller/base.rb:532:in `send' [RAILS_ROOT]/vendor/rails/actionpack/lib/action_controller/base.rb:532:in `process_without_filters' [RAILS_ROOT]/vendor/rails/actionpack/lib/action_controller/filters.rb:606:in `process' [RAILS_ROOT]/vendor/rails/actionpack/lib/action_controller/base.rb:391:in `process' [RAILS_ROOT]/vendor/rails/actionpack/lib/action_controller/base.rb:386:in `call' [RAILS_ROOT]/vendor/rails/actionpack/lib/action_controller/routing/route_set.rb:437:in `call' [RAILS_ROOT]/vendor/rails/actionpack/lib/action_controller/dispatcher.rb:87:in `dispatch' [RAILS_ROOT]/vendor/rails/actionpack/lib/action_controller/dispatcher.rb:121:in `_call' [RAILS_ROOT]/vendor/rails/actionpack/lib/action_controller/dispatcher.rb:130:in `build_middleware_stack' [RAILS_ROOT]/vendor/rails/activerecord/lib/active_record/query_cache.rb:29:in `call' [RAILS_ROOT]/vendor/rails/activerecord/lib/active_record/query_cache.rb:29:in `call' [RAILS_ROOT]/vendor/rails/activerecord/lib/active_record/connection_adapters/abstract/query_cache.rb:34:in `cache' [RAILS_ROOT]/vendor/rails/activerecord/lib/active_record/query_cache.rb:9:in `cache' [RAILS_ROOT]/vendor/rails/activerecord/lib/active_record/query_cache.rb:28:in `call' [RAILS_ROOT]/vendor/rails/activerecord/lib/active_record/connection_adapters/abstract/connection_pool.rb:361:in `call' /usr/lib/ruby/gems/1.8/gems/passenger-2.2.5/vendor/rack-1.0.0-git/lib/rack/head.rb:9:in `call' /usr/lib/ruby/gems/1.8/gems/passenger-2.2.5/vendor/rack-1.0.0-git/lib/rack/methodoverride.rb:24:in `call' [RAILS_ROOT]/vendor/rails/actionpack/lib/action_controller/params_parser.rb:15:in `call' [RAILS_ROOT]/vendor/rails/actionpack/lib/action_controller/session/cookie_store.rb:93:in `call' [RAILS_ROOT]/vendor/rails/actionpack/lib/action_controller/failsafe.rb:26:in `call' /usr/lib/ruby/gems/1.8/gems/passenger-2.2.5/vendor/rack-1.0.0-git/lib/rack/lock.rb:11:in `call' /usr/lib/ruby/gems/1.8/gems/passenger-2.2.5/vendor/rack-1.0.0-git/lib/rack/lock.rb:11:in `synchronize' /usr/lib/ruby/gems/1.8/gems/passenger-2.2.5/vendor/rack-1.0.0-git/lib/rack/lock.rb:11:in `call' [RAILS_ROOT]/vendor/rails/actionpack/lib/action_controller/dispatcher.rb:106:in `call' /usr/lib/ruby/gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/rack/request_handler.rb:95:in `process_request' /usr/lib/ruby/gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/abstract_request_handler.rb:207:in `main_loop' /usr/lib/ruby/gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/railz/application_spawner.rb:378:in `start_request_handler' /usr/lib/ruby/gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/railz/application_spawner.rb:336:in `handle_spawn_application' /usr/lib/ruby/gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/utils.rb:183:in `safe_fork' /usr/lib/ruby/gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/railz/application_spawner.rb:334:in `handle_spawn_application' /usr/lib/ruby/gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/abstract_server.rb:352:in `__send__' /usr/lib/ruby/gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/abstract_server.rb:352:in `main_loop' /usr/lib/ruby/gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/abstract_server.rb:196:in `start_synchronously' /usr/lib/ruby/gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/abstract_server.rb:163:in `start' /usr/lib/ruby/gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/railz/application_spawner.rb:213:in `start' /usr/lib/ruby/gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/spawn_manager.rb:262:in `spawn_rails_application' /usr/lib/ruby/gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/abstract_server_collection.rb:126:in `lookup_or_add' /usr/lib/ruby/gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/spawn_manager.rb:256:in `spawn_rails_application' /usr/lib/ruby/gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/abstract_server_collection.rb:80:in `synchronize' /usr/lib/ruby/gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/abstract_server_collection.rb:79:in `synchronize' /usr/lib/ruby/gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/spawn_manager.rb:255:in `spawn_rails_application' /usr/lib/ruby/gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/spawn_manager.rb:154:in `spawn_application' /usr/lib/ruby/gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/spawn_manager.rb:287:in `handle_spawn_application' /usr/lib/ruby/gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/abstract_server.rb:352:in `__send__' /usr/lib/ruby/gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/abstract_server.rb:352:in `main_loop' /usr/lib/ruby/gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/abstract_server.rb:196:in `start_synchronously' /usr/lib/ruby/gems/1.8/gems/passenger-2.2.5/bin/passenger-spawn-server:61
    /usr/lib/ruby/1.8/openssl/buffering.rb:178:in `syswrite' /usr/lib/ruby/1.8/openssl/buffering.rb:178:in `do_write' /usr/lib/ruby/1.8/openssl/buffering.rb:192:in `write' /usr/lib/ruby/gems/1.8/gems/ruby-net-ldap-0.0.4/lib/net/ldap.rb:1167:in `search' /usr/lib/ruby/gems/1.8/gems/ruby-net-ldap-0.0.4/lib/net/ldap.rb:1144:in `loop' /usr/lib/ruby/gems/1.8/gems/ruby-net-ldap-0.0.4/lib/net/ldap.rb:1144:in `search' /usr/lib/ruby/gems/1.8/gems/activeldap-1.2.0/lib/active_ldap/adapter/net_ldap.rb:135:in `send' /usr/lib/ruby/gems/1.8/gems/activeldap-1.2.0/lib/active_ldap/adapter/net_ldap.rb:135:in `execute' /usr/lib/ruby/gems/1.8/gems/activeldap-1.2.0/lib/active_ldap/adapter/base.rb:654:in `log' [RAILS_ROOT]/vendor/rails/activesupport/lib/active_support/core_ext/benchmark.rb:10:in `realtime' /usr/lib/ruby/gems/1.8/gems/activeldap-1.2.0/lib/active_ldap/adapter/base.rb:654:in `log' /usr/lib/ruby/gems/1.8/gems/activeldap-1.2.0/lib/active_ldap/adapter/net_ldap.rb:135:in `execute' /usr/lib/ruby/gems/1.8/gems/activeldap-1.2.0/lib/active_ldap/adapter/net_ldap.rb:78:in `search' /usr/lib/ruby/gems/1.8/gems/activeldap-1.2.0/lib/active_ldap/adapter/base.rb:169:in `search' /usr/lib/ruby/gems/1.8/gems/activeldap-1.2.0/lib/active_ldap/adapter/base.rb:270:in `operation' /usr/lib/ruby/gems/1.8/gems/activeldap-1.2.0/lib/active_ldap/timeout.rb:15:in `call' /usr/lib/ruby/gems/1.8/gems/activeldap-1.2.0/lib/active_ldap/timeout.rb:15:in `alarm' /usr/lib/ruby/gems/1.8/gems/activeldap-1.2.0/lib/active_ldap/adapter/base.rb:316:in `with_timeout' /usr/lib/ruby/gems/1.8/gems/activeldap-1.2.0/lib/active_ldap/adapter/base.rb:269:in `operation' /usr/lib/ruby/gems/1.8/gems/activeldap-1.2.0/lib/active_ldap/adapter/base.rb:168:in `search' /usr/lib/ruby/gems/1.8/gems/activeldap-1.2.0/lib/active_ldap/adapter/net_ldap.rb:66:in `search' /usr/lib/ruby/gems/1.8/gems/activeldap-1.2.0/lib/active_ldap/operations.rb:65:in `search' /usr/lib/ruby/gems/1.8/gems/activeldap-1.2.0/lib/active_ldap/operations.rb:279:in `find_every' /usr/lib/ruby/gems/1.8/gems/activeldap-1.2.0/lib/active_ldap/operations.rb:252:in `find_initial' /usr/lib/ruby/gems/1.8/gems/activeldap-1.2.0/lib/active_ldap/operations.rb:217:in `find' [RAILS_ROOT]/app/models/user.rb:13:in `authldap_user' [RAILS_ROOT]/app/models/user.rb:45:in `email' [RAILS_ROOT]/vendor/rails/activerecord/lib/active_record/serializers/xml_serializer.rb:340:in `send' [RAILS_ROOT]/vendor/rails/activerecord/lib/active_record/serializers/xml_serializer.rb:340:in `compute_value' [RAILS_ROOT]/vendor/rails/activerecord/lib/active_record/serializers/xml_serializer.rb:287:in `initialize' [RAILS_ROOT]/vendor/rails/activerecord/lib/active_record/serializers/xml_serializer.rb:199:in `new' [RAILS_ROOT]/vendor/rails/activerecord/lib/active_record/serializers/xml_serializer.rb:199:in `serializable_attributes' [RAILS_ROOT]/vendor/rails/activerecord/lib/active_record/serializers/xml_serializer.rb:199:in `collect' [RAILS_ROOT]/vendor/rails/activerecord/lib/active_record/serializers/xml_serializer.rb:199:in `serializable_attributes' [RAILS_ROOT]/vendor/rails/activerecord/lib/active_record/serializers/xml_serializer.rb:210:in `add_attributes' [RAILS_ROOT]/vendor/rails/activerecord/lib/active_record/serializers/xml_serializer.rb:271:in `serialize' [RAILS_ROOT]/vendor/rails/activesupport/lib/active_support/vendor/builder-2.1.2/builder/xmlbase.rb:134:in `call' [RAILS_ROOT]/vendor/rails/activesupport/lib/active_support/vendor/builder-2.1.2/builder/xmlbase.rb:134:in `_nested_structures' [RAILS_ROOT]/vendor/rails/activesupport/lib/active_support/vendor/builder-2.1.2/builder/xmlbase.rb:58:in `method_missing' [RAILS_ROOT]/vendor/rails/activesupport/lib/active_support/vendor/builder-2.1.2/builder/xmlbase.rb:31:in `tag!' [RAILS_ROOT]/vendor/rails/activerecord/lib/active_record/serializers/xml_serializer.rb:270:in `serialize' [RAILS_ROOT]/vendor/rails/activerecord/lib/active_record/serialization.rb:94:in `to_s' [RAILS_ROOT]/vendor/rails/activerecord/lib/active_record/serializers/xml_serializer.rb:156:in `to_xml' [RAILS_ROOT]/vendor/rails/activesupport/lib/active_support/core_ext/array/conversions.rb:189:in `to_xml' [RAILS_ROOT]/vendor/rails/activesupport/lib/active_support/core_ext/array/conversions.rb:189:in `each' [RAILS_ROOT]/vendor/rails/activesupport/lib/active_support/core_ext/array/conversions.rb:189:in `to_xml' [RAILS_ROOT]/vendor/rails/activesupport/lib/active_support/vendor/builder-2.1.2/builder/xmlbase.rb:134:in `call' [RAILS_ROOT]/vendor/rails/activesupport/lib/active_support/vendor/builder-2.1.2/builder/xmlbase.rb:134:in `_nested_structures' [RAILS_ROOT]/vendor/rails/activesupport/lib/active_support/vendor/builder-2.1.2/builder/xmlbase.rb:58:in `method_missing' [RAILS_ROOT]/vendor/rails/activesupport/lib/active_support/vendor/builder-2.1.2/builder/xmlbase.rb:31:in `tag!' [RAILS_ROOT]/vendor/rails/activesupport/lib/active_support/core_ext/array/conversions.rb:187:in `to_xml' [RAILS_ROOT]/vendor/rails/actionpack/lib/action_controller/base.rb:955:in `render_without_benchmark' [RAILS_ROOT]/vendor/rails/actionpack/lib/action_controller/benchmarking.rb:51:in `render_without_active_scaffold' [RAILS_ROOT]/vendor/rails/activesupport/lib/active_support/core_ext/benchmark.rb:17:in `ms' [RAILS_ROOT]/vendor/rails/activesupport/lib/active_support/core_ext/benchmark.rb:10:in `realtime' [RAILS_ROOT]/vendor/rails/activesupport/lib/active_support/core_ext/benchmark.rb:17:in `ms' [RAILS_ROOT]/vendor/rails/actionpack/lib/action_controller/benchmarking.rb:51:in `render_without_active_scaffold' [RAILS_ROOT]/vendor/plugins/active_scaffold/lib/extensions/action_controller_rendering.rb:13:in `render' [RAILS_ROOT]/app/controllers/rest/users_controller.rb:10:in `index' [RAILS_ROOT]/vendor/rails/actionpack/lib/action_controller/mime_responds.rb:135:in `call' [RAILS_ROOT]/vendor/rails/actionpack/lib/action_controller/mime_responds.rb:135:in `custom' [RAILS_ROOT]/vendor/rails/actionpack/lib/action_controller/mime_responds.rb:179:in `call' [RAILS_ROOT]/vendor/rails/actionpack/lib/action_controller/mime_responds.rb:179:in `respond' [RAILS_ROOT]/vendor/rails/actionpack/lib/action_controller/mime_responds.rb:173:in `each' [RAILS_ROOT]/vendor/rails/actionpack/lib/action_controller/mime_responds.rb:173:in `respond' [RAILS_ROOT]/vendor/rails/actionpack/lib/action_controller/mime_responds.rb:107:in `respond_to' [RAILS_ROOT]/app/controllers/rest/users_controller.rb:9:in `index' [RAILS_ROOT]/vendor/rails/actionpack/lib/action_controller/base.rb:1331:in `send' [RAILS_ROOT]/vendor/rails/actionpack/lib/action_controller/base.rb:1331:in `perform_action_without_filters' [RAILS_ROOT]/vendor/rails/actionpack/lib/action_controller/filters.rb:617:in `call_filters' [RAILS_ROOT]/vendor/rails/actionpack/lib/action_controller/filters.rb:610:in `perform_action_without_benchmark' [RAILS_ROOT]/vendor/rails/actionpack/lib/action_controller/benchmarking.rb:68:in `perform_action_without_rescue' [RAILS_ROOT]/vendor/rails/activesupport/lib/active_support/core_ext/benchmark.rb:17:in `ms' [RAILS_ROOT]/vendor/rails/activesupport/lib/active_support/core_ext/benchmark.rb:10:in `realtime' [RAILS_ROOT]/vendor/rails/activesupport/lib/active_support/core_ext/benchmark.rb:17:in `ms' [RAILS_ROOT]/vendor/rails/actionpack/lib/action_controller/benchmarking.rb:68:in `perform_action_without_rescue' [RAILS_ROOT]/vendor/rails/actionpack/lib/action_controller/rescue.rb:160:in `perform_action_without_flash' [RAILS_ROOT]/vendor/rails/actionpack/lib/action_controller/flash.rb:146:in `perform_action' [RAILS_ROOT]/vendor/rails/actionpack/lib/action_controller/base.rb:532:in `send' [RAILS_ROOT]/vendor/rails/actionpack/lib/action_controller/base.rb:532:in `process_without_filters' [RAILS_ROOT]/vendor/rails/actionpack/lib/action_controller/filters.rb:606:in `process' [RAILS_ROOT]/vendor/rails/actionpack/lib/action_controller/base.rb:391:in `process' [RAILS_ROOT]/vendor/rails/actionpack/lib/action_controller/base.rb:386:in `call' [RAILS_ROOT]/vendor/rails/actionpack/lib/action_controller/routing/route_set.rb:437:in `call' [RAILS_ROOT]/vendor/rails/actionpack/lib/action_controller/dispatcher.rb:87:in `dispatch' [RAILS_ROOT]/vendor/rails/actionpack/lib/action_controller/dispatcher.rb:121:in `_call' [RAILS_ROOT]/vendor/rails/actionpack/lib/action_controller/dispatcher.rb:130:in `build_middleware_stack' [RAILS_ROOT]/vendor/rails/activerecord/lib/active_record/query_cache.rb:29:in `call' [RAILS_ROOT]/vendor/rails/activerecord/lib/active_record/query_cache.rb:29:in `call' [RAILS_ROOT]/vendor/rails/activerecord/lib/active_record/connection_adapters/abstract/query_cache.rb:34:in `cache' [RAILS_ROOT]/vendor/rails/activerecord/lib/active_record/query_cache.rb:9:in `cache' [RAILS_ROOT]/vendor/rails/activerecord/lib/active_record/query_cache.rb:28:in `call' [RAILS_ROOT]/vendor/rails/activerecord/lib/active_record/connection_adapters/abstract/connection_pool.rb:361:in `call' /usr/lib/ruby/gems/1.8/gems/passenger-2.2.5/vendor/rack-1.0.0-git/lib/rack/head.rb:9:in `call' /usr/lib/ruby/gems/1.8/gems/passenger-2.2.5/vendor/rack-1.0.0-git/lib/rack/methodoverride.rb:24:in `call' [RAILS_ROOT]/vendor/rails/actionpack/lib/action_controller/params_parser.rb:15:in `call' [RAILS_ROOT]/vendor/rails/actionpack/lib/action_controller/session/cookie_store.rb:93:in `call' [RAILS_ROOT]/vendor/rails/actionpack/lib/action_controller/failsafe.rb:26:in `call' /usr/lib/ruby/gems/1.8/gems/passenger-2.2.5/vendor/rack-1.0.0-git/lib/rack/lock.rb:11:in `call' /usr/lib/ruby/gems/1.8/gems/passenger-2.2.5/vendor/rack-1.0.0-git/lib/rack/lock.rb:11:in `synchronize' /usr/lib/ruby/gems/1.8/gems/passenger-2.2.5/vendor/rack-1.0.0-git/lib/rack/lock.rb:11:in `call' [RAILS_ROOT]/vendor/rails/actionpack/lib/action_controller/dispatcher.rb:106:in `call' /usr/lib/ruby/gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/rack/request_handler.rb:95:in `process_request' /usr/lib/ruby/gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/abstract_request_handler.rb:207:in `main_loop' /usr/lib/ruby/gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/railz/application_spawner.rb:378:in `start_request_handler' /usr/lib/ruby/gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/railz/application_spawner.rb:336:in `handle_spawn_application' /usr/lib/ruby/gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/utils.rb:183:in `safe_fork' /usr/lib/ruby/gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/railz/application_spawner.rb:334:in `handle_spawn_application' /usr/lib/ruby/gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/abstract_server.rb:352:in `__send__' /usr/lib/ruby/gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/abstract_server.rb:352:in `main_loop' /usr/lib/ruby/gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/abstract_server.rb:196:in `start_synchronously' /usr/lib/ruby/gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/abstract_server.rb:163:in `start' /usr/lib/ruby/gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/railz/application_spawner.rb:213:in `start' /usr/lib/ruby/gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/spawn_manager.rb:262:in `spawn_rails_application' /usr/lib/ruby/gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/abstract_server_collection.rb:126:in `lookup_or_add' /usr/lib/ruby/gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/spawn_manager.rb:256:in `spawn_rails_application' /usr/lib/ruby/gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/abstract_server_collection.rb:80:in `synchronize' /usr/lib/ruby/gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/abstract_server_collection.rb:79:in `synchronize' /usr/lib/ruby/gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/spawn_manager.rb:255:in `spawn_rails_application' /usr/lib/ruby/gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/spawn_manager.rb:154:in `spawn_application' /usr/lib/ruby/gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/spawn_manager.rb:287:in `handle_spawn_application' /usr/lib/ruby/gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/abstract_server.rb:352:in `__send__' /usr/lib/ruby/gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/abstract_server.rb:352:in `main_loop' /usr/lib/ruby/gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/abstract_server.rb:196:in `start_synchronously' /usr/lib/ruby/gems/1.8/gems/passenger-2.2.5/bin/passenger-spawn-server:61
  • Nov 11, 2009
    r1110 (* Ruby/ActiveLdap -> ActiveLdap. ) committed by koutou   -   * Ruby/ActiveLdap -> ActiveLdap.
    * Ruby/ActiveLdap -> ActiveLdap.
  • Nov 11, 2009
    r1109 (* Ruby/ActiveLdap -> ActiveLdap. ) committed by koutou   -   * Ruby/ActiveLdap -> ActiveLdap.
    * Ruby/ActiveLdap -> ActiveLdap.
  • Nov 11, 2009
    r1108 (* add 1.2.1 entry. ) committed by koutou   -   * add 1.2.1 entry.
    * add 1.2.1 entry.
  • Nov 07, 2009
    issue 35 (Can't build an org chart using ActiveLdap 1.2.0) Status changed by koutou   -   Thanks for your patch! It includes a test!!! I've applied your patch with some modifications.
    Status: Fixed
    Thanks for your patch! It includes a test!!! I've applied your patch with some modifications.
    Status: Fixed
  • Nov 07, 2009
    r1107 (* fix has_many association is broken [#35] Patch by cultur...) committed by koutou   -   * fix has_many association is broken [#35] Patch by culturespy. Thanks!!!
    * fix has_many association is broken [#35] Patch by culturespy. Thanks!!!
  • Nov 05, 2009
    issue 35 (Can't build an org chart using ActiveLdap 1.2.0) commented on by culturespy   -   As promised, attached, please find a set of patches which: 1) correct the behavior of has_many without :wrap, in the case where the primary and foreign key names are not the same 2) causes has_many :wrap to prefer :foreign_key, but allows :primary_key in a backwards compatible manner 3) includes a test for item 1
    As promised, attached, please find a set of patches which: 1) correct the behavior of has_many without :wrap, in the case where the primary and foreign key names are not the same 2) causes has_many :wrap to prefer :foreign_key, but allows :primary_key in a backwards compatible manner 3) includes a test for item 1
  • Nov 05, 2009
    issue 35 (Can't build an org chart using ActiveLdap 1.2.0) commented on by culturespy   -   Ah, the tests I wrote were wrong. Deleted. Ignore the tests. Working on a better patch.
    Ah, the tests I wrote were wrong. Deleted. Ignore the tests. Working on a better patch.
  • Nov 05, 2009
    issue 35 (Can't build an org chart using ActiveLdap 1.2.0) commented on by culturespy   -   I notice that has_many and has_many :wrap both use the same collect_targets method. This appears to be fundamentally incompatible with the option switch for the non-wrap case, unless you also impose the same switch on the :wrap case. The existing tests never show any problem, because it appears that has_many without :wrap is never tested with properties that have different names. With :wrap, collect_targets looks up the wrapped property on the owning class, finds a list of targets, and then looks up those targets on the foreign class. It makes the assumption that "primary_key" names a property on the foreign class. Without :wrap, collect_targets looks up the primary key property on the owning class. Then it searches for foreign class objects that match, but the attribute it uses to search is the same primary key name. The foreign key name is never used. I recommend that either the option switch be reverted, or :wrap be made to use :foreign_key so that its logic matches the non-wrap usage.
    I notice that has_many and has_many :wrap both use the same collect_targets method. This appears to be fundamentally incompatible with the option switch for the non-wrap case, unless you also impose the same switch on the :wrap case. The existing tests never show any problem, because it appears that has_many without :wrap is never tested with properties that have different names. With :wrap, collect_targets looks up the wrapped property on the owning class, finds a list of targets, and then looks up those targets on the foreign class. It makes the assumption that "primary_key" names a property on the foreign class. Without :wrap, collect_targets looks up the primary key property on the owning class. Then it searches for foreign class objects that match, but the attribute it uses to search is the same primary key name. The foreign key name is never used. I recommend that either the option switch be reverted, or :wrap be made to use :foreign_key so that its logic matches the non-wrap usage.
  • Nov 04, 2009
    issue 35 (Can't build an org chart using ActiveLdap 1.2.0) commented on by culturespy   -   Attached, please find patches: 1) adds a check to stop the option swapping if the primary key option is "dn" 2) adds a has_many association between user.dn and user.seeAlso in the test data population function 3) a test for the broken behavior of has_many
    Attached, please find patches: 1) adds a check to stop the option swapping if the primary key option is "dn" 2) adds a has_many association between user.dn and user.seeAlso in the test data population function 3) a test for the broken behavior of has_many
  • Nov 03, 2009
    issue 35 (Can't build an org chart using ActiveLdap 1.2.0) commented on by culturespy   -   I checked out the whole trunk history with git svn and did a bisect. This was complicated by the first good revision and the latest revision being on opposite sides of commits which introduced, removed, or updated the following: 1) gettext 2) rails version changes 3) ruby-ldap version changes 4) semantics of the options for has_many So at each revision, I had to compensate for those factors. I was able to determine where the problem was introduced. This is the "first bad commit": http://ruby-activeldap.googlecode.com/svn/trunk@1021 This is not surprising, since it's the commit that changed the options for has_many.
    I checked out the whole trunk history with git svn and did a bisect. This was complicated by the first good revision and the latest revision being on opposite sides of commits which introduced, removed, or updated the following: 1) gettext 2) rails version changes 3) ruby-ldap version changes 4) semantics of the options for has_many So at each revision, I had to compensate for those factors. I was able to determine where the problem was introduced. This is the "first bad commit": http://ruby-activeldap.googlecode.com/svn/trunk@1021 This is not surprising, since it's the commit that changed the options for has_many.
  • Nov 03, 2009
    issue 35 (Can't build an org chart using ActiveLdap 1.2.0) commented on by culturespy   -   Tested against svn r1105, still broken.
    Tested against svn r1105, still broken.
  • Nov 03, 2009
    issue 34 (new_entry? on existing instantiated LDAP object always retur...) commented on by czytom   -   In fact I get true on user.save Other thing is that user.new_entry should show true only if it does not exist in ldap.
    In fact I get true on user.save Other thing is that user.new_entry should show true only if it does not exist in ldap.
  • Nov 02, 2009
    issue 35 (Can't build an org chart using ActiveLdap 1.2.0) reported by culturespy   -   I have a model that uses has_many to reference itself to build a tree. It's my "Person" class, so this represents an org chart. Each record's "manager" field contains the dn of that person's supervisor. The root of the chart is a person who is their own manager. I have updated from 1.0.9 to 1.2.0, and now the org chart doesn't work. In the deprecation that was created in has_many to warn users about the need to swap the primary and foreign key options, since my new primary key is "dn" it always gets swapped. (This is because the "dn" attribute doesn't exist for newly created objects?) So I have to comment out the deprecation to get around it thinking I did it wrong. I know I built my model correctly because it worked fine in 1.0.9 and I followed the directions to swap the options. Even if I comment the deprecation out, I still cannot get back the proper list of subordinates. With the sample code and data given below, this query Person.find('employee2').subordinates should come back with employee4's record. Instead, I get employee2. However Person.find('employee4').manager does correctly return employee2's record. Also, Person.find('employee1').subordinates only returns employee1, when I should see employees 1 through 3. Using: ActiveLdap 1.2.0 and OpenLDAP 2.4.11 on Linux 64 bit Model: class Person < ActiveLdap::Base ldap_mapping :dn_attribute => 'uid', :prefix => 'ou=People', :classes => ['top', 'inetOrgPerson'], :scope => :sub #This is the association as it should be for ActiveLdap 1.2.0 has_many :subordinates, :class => "Person", :foreign_key => "manager", :primary_key => "dn" #This is the association that worked under ActiveLdap 1.0.9 # has_many :subordinates, # :class => "Person", # :foreign_key => "dn", # :primary_key => "manager" end LDIF: dn: dc=localhost dc: localhost o: Local Host objectClass: top objectClass: dcObject objectClass: organization dn: ou=People,dc=localhost objectClass: organizationalUnit ou: People dn: uid=employee1,ou=People,dc=localhost objectClass: inetOrgPerson uid: employee1 sn: One cn: Employee One manager: uid=employee1,ou=People,dc=localhost dn: uid=employee2,ou=People,dc=localhost objectClass: inetOrgPerson uid: employee2 sn: Two cn: Employee Two manager: uid=employee1,ou=People,dc=localhost dn: uid=employee3,ou=People,dc=localhost objectClass: inetOrgPerson uid: employee3 sn: Three cn: Employee Three manager: uid=employee1,ou=People,dc=localhost dn: uid=employee4,ou=People,dc=localhost objectClass: inetOrgPerson uid: employee4 sn: Four cn: Employee Four manager: uid=employee2,ou=People,dc=localhost
    I have a model that uses has_many to reference itself to build a tree. It's my "Person" class, so this represents an org chart. Each record's "manager" field contains the dn of that person's supervisor. The root of the chart is a person who is their own manager. I have updated from 1.0.9 to 1.2.0, and now the org chart doesn't work. In the deprecation that was created in has_many to warn users about the need to swap the primary and foreign key options, since my new primary key is "dn" it always gets swapped. (This is because the "dn" attribute doesn't exist for newly created objects?) So I have to comment out the deprecation to get around it thinking I did it wrong. I know I built my model correctly because it worked fine in 1.0.9 and I followed the directions to swap the options. Even if I comment the deprecation out, I still cannot get back the proper list of subordinates. With the sample code and data given below, this query Person.find('employee2').subordinates should come back with employee4's record. Instead, I get employee2. However Person.find('employee4').manager does correctly return employee2's record. Also, Person.find('employee1').subordinates only returns employee1, when I should see employees 1 through 3. Using: ActiveLdap 1.2.0 and OpenLDAP 2.4.11 on Linux 64 bit Model: class Person < ActiveLdap::Base ldap_mapping :dn_attribute => 'uid', :prefix => 'ou=People', :classes => ['top', 'inetOrgPerson'], :scope => :sub #This is the association as it should be for ActiveLdap 1.2.0 has_many :subordinates, :class => "Person", :foreign_key => "manager", :primary_key => "dn" #This is the association that worked under ActiveLdap 1.0.9 # has_many :subordinates, # :class => "Person", # :foreign_key => "dn", # :primary_key => "manager" end LDIF: dn: dc=localhost dc: localhost o: Local Host objectClass: top objectClass: dcObject objectClass: organization dn: ou=People,dc=localhost objectClass: organizationalUnit ou: People dn: uid=employee1,ou=People,dc=localhost objectClass: inetOrgPerson uid: employee1 sn: One cn: Employee One manager: uid=employee1,ou=People,dc=localhost dn: uid=employee2,ou=People,dc=localhost objectClass: inetOrgPerson uid: employee2 sn: Two cn: Employee Two manager: uid=employee1,ou=People,dc=localhost dn: uid=employee3,ou=People,dc=localhost objectClass: inetOrgPerson uid: employee3 sn: Three cn: Employee Three manager: uid=employee1,ou=People,dc=localhost dn: uid=employee4,ou=People,dc=localhost objectClass: inetOrgPerson uid: employee4 sn: Four cn: Employee Four manager: uid=employee2,ou=People,dc=localhost
  • Nov 01, 2009
    issue 34 (new_entry? on existing instantiated LDAP object always retur...) Status changed by koutou   -   There is a built-in validation for it. You will get false on "user.save" and user.errors will include "DN is duplicated: ..." message.
    Status: Invalid
    There is a built-in validation for it. You will get false on "user.save" and user.errors will include "DN is duplicated: ..." message.
    Status: Invalid
  • Oct 30, 2009
    issue 34 (new_entry? on existing instantiated LDAP object always retur...) reported by czytom   -   What steps will reproduce the problem? 1. create instance of existing entry in LDAP class User < ActiveLdap::Base ldap_mapping :dn_attribute => "cn", :classes => ["inetOrgPerson"], :prefix => "ou=People" end 2. create new entry (after connecting to LDAP of course) user = User.new("me") user.new_entry? # return true user.save 3. instantiate existing entry user = User.new("me") user.new_entry?("me") #returns true At first new_entry? should return false, but more important is other issue. For me it seems that instantiating new objects which already is in LDAP must throw some exception - You can modify existing record in LDAP when thinking that it is newly created one. For existing objects You should use find method. I give You one example from my Rails app: You try to create existing entry with cn=John. When you enter create controller's method you want to use new method on that object (which should create new unique object) but instead you are updating currently existing one without that knowledge. What is the expected output? What do you see instead? What version of the product are you using? On what operating system? Please provide any additional information below.
    What steps will reproduce the problem? 1. create instance of existing entry in LDAP class User < ActiveLdap::Base ldap_mapping :dn_attribute => "cn", :classes => ["inetOrgPerson"], :prefix => "ou=People" end 2. create new entry (after connecting to LDAP of course) user = User.new("me") user.new_entry? # return true user.save 3. instantiate existing entry user = User.new("me") user.new_entry?("me") #returns true At first new_entry? should return false, but more important is other issue. For me it seems that instantiating new objects which already is in LDAP must throw some exception - You can modify existing record in LDAP when thinking that it is newly created one. For existing objects You should use find method. I give You one example from my Rails app: You try to create existing entry with cn=John. When you enter create controller's method you want to use new method on that object (which should create new unique object) but instead you are updating currently existing one without that knowledge. What is the expected output? What do you see instead? What version of the product are you using? On what operating system? Please provide any additional information below.
  • Oct 16, 2009
    issue 33 (Strangeness with DN) commented on by koutou   -   > #id= will not be changed. It means #id= behavior will not be changed.
    > #id= will not be changed. It means #id= behavior will not be changed.
  • Oct 16, 2009
    issue 33 (Strangeness with DN) commented on by koutou   -   #rdn= will work like you want but #id= will not be changed. {before,after}_create are invoked just for new entries. {before,after}_save are invoked for all entries.
    #rdn= will work like you want but #id= will not be changed. {before,after}_create are invoked just for new entries. {before,after}_save are invoked for all entries.
  • Oct 16, 2009
    issue 32 (Modify RDN does not work in update_attributes for dn_attribu...) commented on by koutou   -   I worry about dangerousness on programmer not LDAP backend. It's dangerous that mass update causes many programming misses or security problems. What do you think about the dangerousness?
    I worry about dangerousness on programmer not LDAP backend. It's dangerous that mass update causes many programming misses or security problems. What do you think about the dangerousness?
  • Oct 15, 2009
    TroubleShooting (The answers to frequently occurring problems) Wiki page commented on by koutou   -   I've added an answer for your question.
    I've added an answer for your question.
  • Oct 15, 2009
    TroubleShooting (The answers to frequently occurring problems) Wiki page edited by koutou   -   Revision r1106 Edited wiki page through web user interface.
    Revision r1106 Edited wiki page through web user interface.
  • Oct 14, 2009
    issue 33 (Strangeness with DN) commented on by Alexey.Chebotar   -   What this method will do? What will be with method #id= ? I will try check it with before_save or before_validation little bit later P.S. Will be great if you can make works all callbacks (like before_create).
    What this method will do? What will be with method #id= ? I will try check it with before_save or before_validation little bit later P.S. Will be great if you can make works all callbacks (like before_create).
  • Oct 14, 2009
    issue 32 (Modify RDN does not work in update_attributes for dn_attribu...) commented on by Alexey.Chebotar   -   Hi koutou. Sorry, Now I'm very busy with project... I think change RDN by mass update not so dangerous for 'hdb' database; But how I remember 'bdb' database can have problems with this.. Problem was described in thread: Question about children with different objectClass http://rubyforge.org/pipermail/ruby-activeldap-discuss/2009-June/000833.html
    Hi koutou. Sorry, Now I'm very busy with project... I think change RDN by mass update not so dangerous for 'hdb' database; But how I remember 'bdb' database can have problems with this.. Problem was described in thread: Question about children with different objectClass http://rubyforge.org/pipermail/ruby-activeldap-discuss/2009-June/000833.html
  • Oct 14, 2009
    TroubleShooting (The answers to frequently occurring problems) Wiki page commented on by jason.meinzer   -   How do I access the value of fields like createTimeStamp?
    How do I access the value of fields like createTimeStamp?
  • Oct 11, 2009
    issue 33 (Strangeness with DN) commented on by koutou   -   It seems that different behavior on create/save causes confusion. What about creating #rdn= method? P.S. It seems that you should use before_save or before_validation not validate_on_create.
    It seems that different behavior on create/save causes confusion. What about creating #rdn= method? P.S. It seems that you should use before_save or before_validation not validate_on_create.
  • Oct 11, 2009
    r1105 (* DN attribute change by mass assignment with :id => ... blo...) committed by koutou   -   * DN attribute change by mass assignment with :id => ... blocks.
    * DN attribute change by mass assignment with :id => ... blocks.
  • Oct 11, 2009
    issue 32 (Modify RDN does not work in update_attributes for dn_attribu...) commented on by koutou   -   It's intended work. We blocks DN attribute change by mass update by default. (objectClass is also blocked by default) The current update_attributes(:id => ...) behavior is a bug. It seems that RDN change by mass update is dangerous. If it's not dangerous, we will not block DN attribute change by mass update by default.
    It's intended work. We blocks DN attribute change by mass update by default. (objectClass is also blocked by default) The current update_attributes(:id => ...) behavior is a bug. It seems that RDN change by mass update is dangerous. If it's not dangerous, we will not block DN attribute change by mass update by default.
  • Oct 11, 2009
    r1104 (* remove needless cache reset. ) committed by koutou   -   * remove needless cache reset.
    * remove needless cache reset.
  • Oct 10, 2009
    issue 33 (Strangeness with DN) reported by Alexey.Chebotar   -   What steps will reproduce the problem? 1. Create model role.rb: class Role < ActiveLdap::Base ldap_mapping :dn_attribute => 'i2Canonic', :prefix => 'ou=domains', :classes => ['Role'], :scope => :one, :sort_by => 'i2Canonic' attr_accessor :i2Domain private def validate_on_create unless self.id.blank? unless self.i2Domain.blank? roles = OrgUnit.find(:attribute => "ou", :value => "roles", :prefix => "dc=#{self.i2Domain},ou=domains") self.dn = "#{self.dn_attribute}=#{self.id},#{roles.dn}" end end end end 2. Run script/console 3. Create new Role: ?> role = Role.create(:i2Canonic => "USER3", :i2Name => "User", :i2Domain => "test3.com") => #<Role objectClass:<Role>, must:<i2Canonic, i2Name>, may:<description, i2Right>, description: [], i2Canonic: ["USER2"], i2Name: ["User"], i2Right: [], objectClass: ["Role"]> Checking value of DN: >> old_rdn = role.id => "USER3" >> role.base => #<ActiveLdap::DistinguishedName:0xa02c4a8 @rdns=[{"ou"=>"roles"}, {"dc"=>"test3.com"}, {"ou"=>"domains"}, {"dc"=>"..."}, {"dc"=>""}, {"dc"=>""}, {"dc"=>"com"}]> >> old_dn = role.dn => #<ActiveLdap::DistinguishedName:0xa017844 @rdns= [{"i2Canonic"=>"USER3"}, {"ou"=>"roles"}, {"dc"=>"test3.com"}, {"ou"=>"domains"}, {"dc"=>"..."}, {"dc"=>""}, {"dc"=>""}, {"dc"=>"com"}]> I trying change id (The same happens when I trying change rdn) >> role.id = "USER2" => "USER2" >> role.base => #<ActiveLdap::DistinguishedName:0xa02c4a8 @rdns=[{"ou"=>"roles"}, {"dc"=>"test3.com"}, {"ou"=>"domains"}, {"dc"=>"..."}, {"dc"=>""}, {"dc"=>""}, {"dc"=>"com"}]> Here is strange behavior: >> role.dn => #<ActiveLdap::DistinguishedName:0x9ee6474 @rdns= [{"i2Canonic"=>"USER2"}, {"ou"=>"domains"}, {"dc"=>"..."}, {"dc"=>""}, {"dc"=>""}, {"dc"=>"com"}]> >> role.base => #<ActiveLdap::DistinguishedName:0xa342a7c @rdns=[{"ou"=>"domains"}, {"dc"=>"..."}, {"dc"=>""}, {"dc"=>""}, {"dc"=>"com"}]> So, when I tried save record, I got error: ?> role.save ActiveLdap::NotImplemented: not implemented: modify RDN with new superior from /usr/lib/ruby/gems/1.9.1/gems/activeldap-1.2.0/lib/active_ldap/ adapter/ldap.rb:162:in `block in modify_rdn' from /usr/lib/ruby/gems/1.9.1/gems/activeldap-1.2.0/lib/active_ldap/ adapter/base.rb:238:in `block in modify_rdn' from /usr/lib/ruby/gems/1.9.1/gems/activeldap-1.2.0/lib/active_ldap/ adapter/base.rb:270:in `block in operation' from /usr/lib/ruby/gems/1.9.1/gems/activeldap-1.2.0/lib/active_ldap/ timeout.rb:15:in `call' from /usr/lib/ruby/gems/1.9.1/gems/activeldap-1.2.0/lib/active_ldap/ timeout.rb:15:in `alarm' from /usr/lib/ruby/gems/1.9.1/gems/activeldap-1.2.0/lib/active_ldap/ adapter/base.rb:316:in `with_timeout' from /usr/lib/ruby/gems/1.9.1/gems/activeldap-1.2.0/lib/active_ldap/ adapter/base.rb:269:in `operation' from /usr/lib/ruby/gems/1.9.1/gems/activeldap-1.2.0/lib/active_ldap/ adapter/base.rb:237:in `modify_rdn' from /usr/lib/ruby/gems/1.9.1/gems/activeldap-1.2.0/lib/active_ldap/ adapter/ldap.rb:160:in `modify_rdn' from /usr/lib/ruby/gems/1.9.1/gems/activeldap-1.2.0/lib/active_ldap/ operations.rb:559:in `modify_rdn_entry' from /usr/lib/ruby/gems/1.9.1/gems/activeldap-1.2.0/lib/active_ldap/ base.rb:1562:in `block in update' from /usr/lib/ruby/gems/1.9.1/gems/activeldap-1.2.0/lib/active_ldap/ base.rb:1526:in `prepare_data_for_saving' from /usr/lib/ruby/gems/1.9.1/gems/activeldap-1.2.0/lib/active_ldap/ base.rb:1551:in `update' from /usr/lib/ruby/gems/1.9.1/gems/activerecord-2.3.4/lib/active_record/ callbacks.rb:282:in `update_with_callbacks' from /usr/lib/ruby/gems/1.9.1/gems/activeldap-1.2.0/lib/active_ldap/ base.rb:1511:in `create_or_update' from /usr/lib/ruby/gems/1.9.1/gems/activerecord-2.3.4/lib/active_record/ callbacks.rb:250:in `create_or_update_with_callbacks' from /usr/lib/ruby/gems/1.9.1/gems/activeldap-1.2.0/lib/active_ldap/ base.rb:816:in `save' from /usr/lib/ruby/gems/1.9.1/gems/activerecord-2.3.4/lib/active_record/ validations.rb:1078:in `save_with_validation' from (irb):182 from /usr/bin/irb:12:in `<main>'>> ?> I would suggest solution: Generate new DN from old DN and replace old rdn when not present new_superior (only for created records) ?> role.dn = old_dn.to_s.gsub("USER3", "USER2") => "i2Canonic=USER2,ou=roles,dc=test3.com,ou=domains,dc=...,dc=...,dc=...,dc=com" >> ?> role.save => true LDAP: modify: RDN (4.1ms): {:dn=>"i2Canonic=USER3,ou=roles,dc=test3.com,ou=domains,dc=...,dc=...,dc=...,dc=com", :new_rdn=>"i2Canonic=USER2", :new_superior=>nil, :delete_old_rdn=>true}
    What steps will reproduce the problem? 1. Create model role.rb: class Role < ActiveLdap::Base ldap_mapping :dn_attribute => 'i2Canonic', :prefix => 'ou=domains', :classes => ['Role'], :scope => :one, :sort_by => 'i2Canonic' attr_accessor :i2Domain private def validate_on_create unless self.id.blank? unless self.i2Domain.blank? roles = OrgUnit.find(:attribute => "ou", :value => "roles", :prefix => "dc=#{self.i2Domain},ou=domains") self.dn = "#{self.dn_attribute}=#{self.id},#{roles.dn}" end end end end 2. Run script/console 3. Create new Role: ?> role = Role.create(:i2Canonic => "USER3", :i2Name => "User", :i2Domain => "test3.com") => #<Role objectClass:<Role>, must:<i2Canonic, i2Name>, may:<description, i2Right>, description: [], i2Canonic: ["USER2"], i2Name: ["User"], i2Right: [], objectClass: ["Role"]> Checking value of DN: >> old_rdn = role.id => "USER3" >> role.base => #<ActiveLdap::DistinguishedName:0xa02c4a8 @rdns=[{"ou"=>"roles"}, {"dc"=>"test3.com"}, {"ou"=>"domains"}, {"dc"=>"..."}, {"dc"=>""}, {"dc"=>""}, {"dc"=>"com"}]> >> old_dn = role.dn => #<ActiveLdap::DistinguishedName:0xa017844 @rdns= [{"i2Canonic"=>"USER3"}, {"ou"=>"roles"}, {"dc"=>"test3.com"}, {"ou"=>"domains"}, {"dc"=>"..."}, {"dc"=>""}, {"dc"=>""}, {"dc"=>"com"}]> I trying change id (The same happens when I trying change rdn) >> role.id = "USER2" => "USER2" >> role.base => #<ActiveLdap::DistinguishedName:0xa02c4a8 @rdns=[{"ou"=>"roles"}, {"dc"=>"test3.com"}, {"ou"=>"domains"}, {"dc"=>"..."}, {"dc"=>""}, {"dc"=>""}, {"dc"=>"com"}]> Here is strange behavior: >> role.dn => #<ActiveLdap::DistinguishedName:0x9ee6474 @rdns= [{"i2Canonic"=>"USER2"}, {"ou"=>"domains"}, {"dc"=>"..."}, {"dc"=>""}, {"dc"=>""}, {"dc"=>"com"}]> >> role.base => #<ActiveLdap::DistinguishedName:0xa342a7c @rdns=[{"ou"=>"domains"}, {"dc"=>"..."}, {"dc"=>""}, {"dc"=>""}, {"dc"=>"com"}]> So, when I tried save record, I got error: ?> role.save ActiveLdap::NotImplemented: not implemented: modify RDN with new superior from /usr/lib/ruby/gems/1.9.1/gems/activeldap-1.2.0/lib/active_ldap/ adapter/ldap.rb:162:in `block in modify_rdn' from /usr/lib/ruby/gems/1.9.1/gems/activeldap-1.2.0/lib/active_ldap/ adapter/base.rb:238:in `block in modify_rdn' from /usr/lib/ruby/gems/1.9.1/gems/activeldap-1.2.0/lib/active_ldap/ adapter/base.rb:270:in `block in operation' from /usr/lib/ruby/gems/1.9.1/gems/activeldap-1.2.0/lib/active_ldap/ timeout.rb:15:in `call' from /usr/lib/ruby/gems/1.9.1/gems/activeldap-1.2.0/lib/active_ldap/ timeout.rb:15:in `alarm' from /usr/lib/ruby/gems/1.9.1/gems/activeldap-1.2.0/lib/active_ldap/ adapter/base.rb:316:in `with_timeout' from /usr/lib/ruby/gems/1.9.1/gems/activeldap-1.2.0/lib/active_ldap/ adapter/base.rb:269:in `operation' from /usr/lib/ruby/gems/1.9.1/gems/activeldap-1.2.0/lib/active_ldap/ adapter/base.rb:237:in `modify_rdn' from /usr/lib/ruby/gems/1.9.1/gems/activeldap-1.2.0/lib/active_ldap/ adapter/ldap.rb:160:in `modify_rdn' from /usr/lib/ruby/gems/1.9.1/gems/activeldap-1.2.0/lib/active_ldap/ operations.rb:559:in `modify_rdn_entry' from /usr/lib/ruby/gems/1.9.1/gems/activeldap-1.2.0/lib/active_ldap/ base.rb:1562:in `block in update' from /usr/lib/ruby/gems/1.9.1/gems/activeldap-1.2.0/lib/active_ldap/ base.rb:1526:in `prepare_data_for_saving' from /usr/lib/ruby/gems/1.9.1/gems/activeldap-1.2.0/lib/active_ldap/ base.rb:1551:in `update' from /usr/lib/ruby/gems/1.9.1/gems/activerecord-2.3.4/lib/active_record/ callbacks.rb:282:in `update_with_callbacks' from /usr/lib/ruby/gems/1.9.1/gems/activeldap-1.2.0/lib/active_ldap/ base.rb:1511:in `create_or_update' from /usr/lib/ruby/gems/1.9.1/gems/activerecord-2.3.4/lib/active_record/ callbacks.rb:250:in `create_or_update_with_callbacks' from /usr/lib/ruby/gems/1.9.1/gems/activeldap-1.2.0/lib/active_ldap/ base.rb:816:in `save' from /usr/lib/ruby/gems/1.9.1/gems/activerecord-2.3.4/lib/active_record/ validations.rb:1078:in `save_with_validation' from (irb):182 from /usr/bin/irb:12:in `<main>'>> ?> I would suggest solution: Generate new DN from old DN and replace old rdn when not present new_superior (only for created records) ?> role.dn = old_dn.to_s.gsub("USER3", "USER2") => "i2Canonic=USER2,ou=roles,dc=test3.com,ou=domains,dc=...,dc=...,dc=...,dc=com" >> ?> role.save => true LDAP: modify: RDN (4.1ms): {:dn=>"i2Canonic=USER3,ou=roles,dc=test3.com,ou=domains,dc=...,dc=...,dc=...,dc=com", :new_rdn=>"i2Canonic=USER2", :new_superior=>nil, :delete_old_rdn=>true}
 
Hosted by Google Code