consumer.begin(cgi['openid'])fails with
undefined method `chr' for "foo":String
/var/lib/gems/1.8/gems/ruby-openid-2.0.2/l
/var/lib/gems/1.8/gems/ruby-openid-2.0.2/l
/var/lib/gems/1.8/gems/ruby-openid-2.0.2/l
/usr/lib/ruby/1.8/rubygems/custom_requir
/var/lib/gems/1.8/gems/ruby-openid-2.0.2/l
/var/lib/gems/1.8/gems/ruby-openid-2.0.2/lThe problem is due to this interesting behavior of the CGI module.
Say you have a CGI parameter called 'foo' with the value of 'bar'. Then the following things are true:
p cgi['foo'] # => 'bar' p cgi['foo'].class # => String p cgi['foo'][0] # => 'bar' p cgi['foo'].to_s[0] # => 'bar' p cgi['foo'].to_str # => 'bar' p cgi['foo'].to_str[0] # => 'bar'This is due to a questionable hack in the CGI module, where the string object is extended with a new method that breaks the string interface. It turns out it prints a warning if you try this:
/var/lib/gems/1.8/gems/ruby-openid-2.0.2/lBut you're typically using OpenID in a web server context and that warning apparently isn't enough to trigger the "internal server error" result.
The fix is to instead use
consumer.begin(cgi.params['openid'][0])where
#params just gives you the parameter value in a hash (with a default value of [] so it's safe to index without checking for the key).I'm clearly rusty on this whole "dynamic language" thing, because I found the above kinda confusing. (Haskell and C++, which are what I mostly hack these days, are pretty different but also quite similar in some aspects of what you can't do.) Hopefully I've stuck enough text in this post for future Googler-seekers to see the problem.
