We use Edge Rails in our projects. Call me stupid if you like, I like living on the edge (get it?). This desire to push our luck has bitten us a couple of times, but not in any serious way. Not until recently anyway. We use OpenID - another brand new cool technology. The combination of Rails and OpenID has been great.
Then one day it all stopped working and my PPH (Profanity Per Hour) went through the roof. We have Capistrano setup. I had another guy deploy 51week and OpenID stopped working and started giving me the dreaded "Sorry, the OpenID verification failed" error. I deployed it and it started working. "Very strange I thought to myself," but I was just glad it was working. Then Joel starts working on igagus. He can't login because of the dreaded "Sorry, the OpenID verification failed". We make some changes and notice that igagus no longer works.
WTF?
So I spend some time searching and can't find anything. I spend some time chatting with the Janrain guys, but they don't know what it is either. Then I set igagus to use an older version of edge rails - the same version that 51weeks is running. It magically starts running so I do some research.
Here's the change in edge rails that breaks OpenID if you are using postgresql. In that change the postgres adapter was modified. The 'secret' used by the OpenID authentication is stored as a bytea column in postgres. In change 7329 the way that bytea columns are dealt with was changed and now the value that is returned from the database is incorrect.
I traced this down into consumer.rb in the ruby-openid gem.
This section of code from around line 562 is where the 'sig mismatch' comes from.
_signed, v_sig = OpenID::Util.sign_reply(args, assoc.secret, signed_list)
if v_sig != sig
return FailureResponse.new(consumer_id, 'sig mismatch')
end
To ensure that the response from the OpenID server is not tampered with the response is signed with a shared secret. When the response is received the reply is checked using the local secret that is stored in the local db as a bytea column. Because of the change in the postgresql adapter the bytea value returned is different than the one originally sent to the OpenID server. The result is mismatched hash which returns the 'sig mismatch' error.
I am currently trying to find the exact problem and an solution. If anyone has any great ideas please let me know.
Tags: edge rails · errors · OpenID · Ruby On Rails7 Comments












7 responses so far ↓
Any luck figuring this one out? I’ve been trying to resolve the same issue myself for the past few weeks, but I’m stuck at this point and don’t know where else to turn. It looks like you’re the only one out there who has documented the issue. I’d post a ticket on the Rails Trac, but I still haven’t figured out exactly where the problem is occurring. I believe that’s it’s somewhere in all the changes to the binary encoding/decoding, but I don’t know enough about the innards of PostgreSQL or Rails to be able to say with any certainty where the culprit lies.
I haven’t had any luck yet. To tell you the truth I haven’t had much time to go back and look at it so for now I have locked my rails version at 7328 so that it keeps working. Scary thing is that until this problem is fixed I won’t be able to move to the newest version of rails.
Run this:
rake rails:freeze:edge REVISION=7328
and you will be back up and running for now.
Poking around with this very issue tonite it would appear that the changeset is broken in the docoding of bytea’s (lines 78 and 88) the regexp should be /\\\d{3}/ not /\\\\\d{3}/ as it is in both cases.
A bit of tinkering has shown me the main use for byteas (images) often have a \ followed by a character that requires encoding so they generally match the original regexp and therefore nothing is noticed.
Darrin, thanks for the post. That does indeed seem to fix the issue. Have you submitted this as a patch? I ran the unit tests for ActiveRecord after making the change, and everything passed, though I suppose there should be a test created to prove the validity of the fix.
I submitted a ticket for this issue. We’ll see if a fix shows up in Rails 2.0.
I turned your fix into a patch with a failing test.
Hopefully it will be merged in time for Rails 2.0.
Thanks!!
It’s been merged.