Self-esteem expressed in Ruby

It’s a valuable life lesson made incredibly concise in my favourite programming language, Ruby. I leave the interpretation to the reader. It relates to some themes that I’ve already written about before and will probably write more about in the future.

As with the first tutorial, I’ve pushed a branch based on authlogic_example that you can use as a concrete example.

First, let’s bring in the declarative_authorization gem:

# My example code was written before GitHub decided that they don't want to
# build gems anymore but this line should do the trick.
config.gem "declarative_authorization", :source => 'http://gemcutter.org'

Now, we need to make an ActiveLdap model class like LdapUser but for groups. We’ll call this LdapGroup:

class LdapGroup < ActiveLdap::Base
  ldap_mapping :dn_attribute => "cn",
    :scope => :sub,
    :prefix => "ou=groups,o=users"
 
  has_many :members, :class_name => "LdapUser", :wrap => "member",
    :primary_key => "dn", :foreign_key => "dn"
end

The ldap_mapping part is very similar to the previous one for LdapUser, but the has_many is where the real ActiveLdap magic starts!

We are letting ActiveLdap know that an LdapGroup has LdapUser members, which are defined in the multi-valued attribute member, where each of the values is the DN of an LdapUser. If you’re looking for a bit more detail, refer to the ActiveLdap documentation. Keep in mind that the code above is for the specific schema used by my example application and you may have to change it to match yours.

With that, we should be able to list all of our LDAP groups and find the members of any particular one in the console:

>> LdapGroup.all.collect { |g| g.cn }
=> ["super_admin"]
>> LdapGroup.find("super_admin").members.collect { |m| m.dn }
=> ["uid=ebianco,o=users,dc=example,dc=com"]

Now we’ll create an association between LdapUser and LdapGroup so that given a user, we can figure out which groups he/she is a member of. We’re going to tell ActiveLdap that a user’s groups are those groups in which the user’s DN appears in the group’s member attribute:

belongs_to :groups, :class_name => "LdapGroup", :many => "member",
  :foreign_key => "dn"

Let’s check our handiwork in the console:

>> LdapUser.find("ebianco").groups.collect { |g| g.cn }
=> ["super_admin"]

Now why did we go through all of this effort? declarative_authorization allows us to provide an instance method for User, #role_symbols, that returns an array of symbols representing the list of roles that the user has. With our ActiveLdap setup, mapping a user’s roles to LDAP groups becomes a one-liner:

def role_symbols
  ldap_entry.groups.collect { |g| g.cn.to_sym }
end

From here, we can define the authorization rules for our LDAP-based roles. declarative_authorization reads these from config/authorization_rules.rb:

authorization do
  role :super_admin do
    has_permission_on :users, :to => :manage
  end
  role :guest do
    has_permission_on :users, :to => :read
    has_permission_on :users, :to => [:create, :update, :destroy] do
      if_attribute :id => is {user.id}
    end
  end
 
end
 
privileges do
  privilege :manage do
    includes :create, :read, :update, :destroy
  end
end

Now we can use declarative_authorization as usual. I won’t go through all the details but if you want a primer on using declarative_authorization, you can start here and browse the commits on my authlogic_example branch.

class WebTransaction
 
  # Base URL for transaction web service
  SERVICE_URL = "http://accountingservice.com/"
 
  def transaction_url
    url = SERVICE_URL
    url << "VAL1=foo"
    url << "&VAL2=bar"
    url
  end
 
end

The class is meant to represent a transaction being posted against a rather odd web service that actually uses GET rather than POST for posting transactions (bad web service!). In my actual code, the URL parameters appended to the SERVICE_URL base would be determined on a per-object basis but I’ve simplified it here.

Here’s the punchline: SERVICE_URL was changing! Calls to transaction_url would keep on appending more variables to it. If you’re particularly clever with Ruby, you’ve already figured out exactly why. But if you’re scratching your head like I was, here are some hints:

• In Ruby, constants aren’t. In fact, they’re really no different from variables except for the fact that Ruby detects that variable names in all-caps are probably supposed to stay constant and warns if you try to assign to them.
• <<, for strings, will append to the end of the string.
• Ruby strings are mutable. That is, operations on a string variable will usually be done in place, rather than returning a new string. (Method calls, on the other hand, are a different story!)
• Assigning a String variable to another String variable will assign the reference. That is, the two variables will be pointing at the same object.

Hit the jump to see the solution to this little mystery…

SERVICE_URL is only directly assigned to when it is declared. But what happens when I assign SERVICE_URL to the local variable in transaction_url, url. They’re pointing to the same object!

Then I go ahead and I start appending things to the end of the string. Ruby has no complaints because I’m not assigning to SERVICE_URL but the object that it is pointing to is being changed! The operation is causing the URL parameters to be appended in place.

And that, friends, is what happens when constants aren’t. Let’s fix this little error:

class WebTransaction
 
  # Base URL for transaction web service
  SERVICE_URL = "http://accountingservice.com/"
 
  def transaction_url
    url = SERVICE_URL.clone
    url << "VAL1=foo"
    url << "&VAL2=bar"
    url
  end
 
end

Now, instead of appending to the string object referenced by SERVICE_URL directly, I’m creating a copy of the object and then appending URL parameters to that.

This branch shows a way of implementing pass-through authentication to an LDAP server using ActiveLdap and Authlogic, with just some small changes to the User and UserSession models.

First, we’ll need to bring in the net-ldap and activeldap gems. We edit config/environment.rb to include the following two lines:

config.gem "net-ldap", :lib => false, :version => '>=0.0.5'
config.gem "activeldap", :lib => "active_ldap", :version => '1.0.9'

If you use sudo gem install net-ldap, you’ll get 0.0.4. Here, I’ve built the 0.0.5 gem from the GitHub repo. This is because there are some bug fixes in the GitHub master that aren’t in the RubyForge gem. In the with-activeldap branch, the two gems are vendored.

Now, we create config/ldap.yml to configure ActiveLdap’s connection to our LDAP server. Here’s mine:

development:
  host: 127.0.0.1
  base: dc=dev,dc=Asuka,dc=local
  bind_dn: cn=Manager,dc=dev,dc=Asuka,dc=local
  password: secret
 
test:
  host: 127.0.0.1
  base: dc=test,dc=Asuka,dc=local
  bind_dn: cn=Manager,dc=Asuka,dc=local
  password: secret
 
production:
  host: 127.0.0.1
  base: dc=prod,dc=Asuka,dc=local
  bind_dn: cn=Manager,dc=Asuka,dc=local
  password: secret

This tells ActiveLdap the server/port to connect to, what the base entry for our LDAP objects is, and what user to bind as for operations on the server. Now, we create a LdapUser class to represent user entries in the LDAP:

class LdapUser < ActiveLdap::Base
  ldap_mapping :dn_attribute => "uid",
    :scope => :sub,
    :prefix => "o=users"
end

This defines an LDAP user as being an entry from the o=users organization, where all of the entries are distinguished by the uid attribute. Now, we should be able to use the console to list all of our LDAP users like so:

 >> LdapUser.all

Now, we’ll add some methods to the User model that allow us to look up users by login in the LDAP and create entries in the database if they don’t already exist. We’ll also need a method for forwarding the credentials provided on the login form to the LDAP and see if they are valid:

class User < ActiveRecord::Base
  acts_as_authentic do |c|
    # Don't validate password, since that will be held in the LDAP
    c.validate_password_field = false
  end
 
  def ldap_entry
    LdapUser.find(self.login)
  end
 
  # Tries to find a User first by looking into the database and then by
  # creating a User if there's an LDAP entry for the given login
  def self.find_or_create_from_ldap(login)
    find_by_login(login) || create_from_ldap_if_valid(login)
  end
 
  # Creates a User record in the database if there is an entry in the LDAP
  # with the given login
  def self.create_from_ldap_if_valid(login)
    begin
      User.create(:login => login) if LdapUser.find(login)
    rescue ActiveLdap::EntryNotFound
      nil # Don't do anything since we can't find an entry
    end
  end
 
  protected
    # Authenticates the user against the LDAP.
    def valid_ldap_credentials?(password_plaintext)
      ldap_entry.bind(password_plaintext)
      ldap_entry.remove_connection
      true
    rescue ActiveLdap::AuthenticationError, ActiveLdap::LdapError::UnwillingToPerform
      false
    end
end

With this, there is no longer a need for the crypted_password and password_salt columns in the users table, so if those columns exist, you’ll have to write a migration to remove them (or at least allow NULL values for them). Now, we modify the UserSession to use our custom methods for looking up users and validating their credentials:

class UserSession < Authlogic::Session::Base
  find_by_login_method :find_or_create_from_ldap
  verify_password_method :valid_ldap_credentials?
end

With that, we should now be able to log in as a user by providing her uid as the login and the password. LDAP pass-through authentication achieved! There is a downside though: ActiveLdap is not particularly efficient with its queries but this can be mitigated by storing the user’s LDAP entry (the LdapUser object) in the User instance when it is first looked up.

def ldap_entry
  @ldap_entry ||= LdapUser.find(self.login)
end

In a future post, I will extend this further by modeling LDAP groups and bringing in declarative_authorization to implement role-based access control based on LDAP group membership.

Why The Lucky Stiff’s contributions to the Ruby community include “Why’s Poignant Guide to Ruby”, a book which many state was the reason they got into Ruby, Shoes, an easy-to-use cross-platform GUI toolkit with innovative online distribution features, and Hpricot, a very slick HTML parser that is also a joy to use.

Some believe that he has decided to move on from software development because his last tweet reads “programming is rather thankless. u see your works become replaced by superior ones in a year. unable to run at all in a few more.” Some believe that his accounts were all hacked. A few others believe that his anonymity has been compromised and that he has decided the destroy the pseudonym.

Wherever Why The Lucky Stiff goes from here, I hope he knows that there are so many of us who looked up to him and have him to thank for knowing the joy that is programming in Ruby. He will be sorely missed.

It turns out that ActiveScaffold and YARD don’t play nice together. In particular, if YARD has previously been loaded (say, to define a Rake task for it), ActiveScaffold initialization will fail with the following error:

uninitialized constant Helpers::ControllerHelpers

Using --trace and following the source code, I find out that this is happening during ActiveScaffold’s initialization, particularly at this statement:

ActionController::Base.send(:include, ActiveScaffold::Helpers::ControllerHelpers)

Debugging the ActiveScaffold initialization code yields this baffling result:

>> ActiveScaffold::Helpers
=> Helpers
>> ActiveScaffold::Helpers::ControllerHelpers
NameError: uninitialized constant ActiveScaffold::Helpers

It’s the weirdest thing that I’ve seen since I became a Rubyist and it is blocking me from using YARD to generate the documentation for my current Rails project. Unfortunately, cutting out ActiveScaffold isn’t going to fly because the deadline for initial release is so close and so much functionality is implemented using it already. It wasn’t my choice; if I had my way, I might never use ActiveScaffold ever again.

It’s the same reason why scientists have by and large stopped explaining away the world with “God”. Saying that something in our natural world is “magic” or the work of a “God” is a cop-out. Why even study the world at all? We could just say it’s all hocus-pocus and never have to worry about it! The same idea can apply to programming as well.

I used to think that Ruby meta-programming was dark magic. I didn’t understand any of it and felt like I just couldn’t break through the barrier of clever one-liners and idioms, but I started to read the source code of Ruby projects that I used in my day job and side projects. I studied carefully, taking the time to understand even the most complex-looking constructions. I learned some things about Ruby that I didn’t know before and picked up some common patterns. Suddenly, Ruby made a lot more sense and my skill with it grew rapidly. Every day, I’m learning more and more.

So here’s the first part of the message that Giles was trying to deliver: Rails is not magic. It’s Ruby.

(There are also some supplementary thoughts about how, from a Lisp lover’s point of view, languages like Ruby and Python, even with all of their meta-programming power, might be annoying because there is still a subtle distinction between data and code.)

This is not to say that Rails is perfect or pure. The Rails team is making great efforts to bring in ideas from Merb to reduce some of the pain that developers feel when trying to go against the grain of Rails’ conventions. I am very much looking forward to Rails 3 and I think many others in the Rails developer community are too. But it is not “dark magic”; it is a tapestry of abstractions (albeit sometimes of the leaky variety) that are weaved together with clever Ruby programming. Maybe some of the code is too clever for its own good but it is a potent demonstration of just how expressive Ruby can be. But the upshot of Rails’ design is that, inevitably, something in Rails won’t behave the way you might desire it to and you will find yourself forced to dive into the source code of the framework to find out why.

While I don’t disagree with the notion that Rails could be documented a lot better, I’ve realized that source code is the most reliable form of documentation. API docs and tutorials and blog posts may be out of date or missing details, but the source code is the current set of instructions that is being given to the computer. It is always the most comprehensive and accurate picture of how the system works at any given moment. And, more frequently than ever, we have the power to dive into the source of the software we use to enhance our understanding where its documentation fails.

Now here comes the second part of what Giles was trying to say:

If you love Ruby (as even some anti-Rails folks do) but you’re vexed by Ruby “magic”, read the source. Study it carefully, ask for help if you need to, and contribute your findings back to the community. But don’t just dismiss it as magic, or you might be missing out on a chance to learn some incredibly useful and powerful things.

While the previous two days had already blown my mind, it seems as though the best had been saved for last.  The day’s talks started with Collin T. Miller giving us his thoughts on how we can move away from text as the primary way of encoding computer programs and move towards other encodings that more closely resemble the domains in which we are trying to solve computing problems. While I found his ideas interesting, I don’t think I can agree with his notion that text should be replaced as the primary encoding for programs. I think that text is an excellent way of representing computer programs: it is concise, easy to manipulate, and easy to parse.

Friday, July 10, 2009

After work, I walked over to the Metropolitan Hotel to get my badge. My kit included a schedule, a large poster, a crimson t-shirt with black Russian-propaganda style Future Ruby logo, a bottle of water, a pack of matches, a patch with the Future Ruby logo on it (for sewing on to backpacks and the like) and a TTC pass valid for the length of the convention. All of this was stuffed inside of a rugged, dark green bag with the Future Ruby patch sewn on it. This is by and far the best swag I’ve ever received at a conference, ever.

After that, I got dinner and headed down to Unspace HQ for a wicked awesome patio party. Unspace HQ seems like an incredible place to work — prime location, lots of outdoor space, and a pretty nice collection of knick knacks, including a working pinball machine — but it is also an excellent space for a party. The highlight of the night for me was seeing two CF18′s doing a fly-by. Although I’m not a huge fan of military hardware, watching the way that they turned through the air was a unique experience.

I went home early to give myself enough time to commute home and get at least 5-6 hours of sleep for the next day.

Here are some of the projects that I’m watching this week:

• jmettraux/ruote: an open source workflow engine built with Ruby. I might be using this for a project I’m working on. Also see jmettraux/ruote-web2 for a demonstration of how to integrate ruote with Ruby on Rails.
• brynary/webrat: automated acceptance testing with Ruby. It can simulate a simple browser on its own or drive a real browser via Selenium. Apparently there’s some work in progress on integrating with Watir and Celerity as well.
• radiant/radiant: RadiantCMS, the lightweight web content management system for Ruby on Rails. I’m contributing a Japanese translation, the current version of which is currently available in the official i18n branch. (also see kbingman/radiant and enricob/radiant)
• chriseppstein/compass: As I wrote previously, Compass is gaining new features at an incredible rate. It now sports improved Rails integration, Blueprint 0.9, an extension system, and asset hosts support. As an added bonus, it no longer depends on edge Haml; it will work with the newest stable release of Haml, 2.2.0. This is one of the most watched repositories on GitHub for a reason — if you’re not already using this, try it today!

I’m sure that I will hear of even more awesome projects at Future Ruby.