Relative root causes different OpenID user tokens after upgrading to Rails 3 with Passenger

Question

We have gmail openid working for more than a year with Redmine 1.3.1 (Rails 2 Mongrel). I have upgraded a separate box to Redmine 2.0.3 (Rails 3 Passenger), but when I switch over from the old instance to the upgraded instance all users are prompted with the Google authorize application screen and if they click yes they are prompted with the Redmine registration screen.

I have transferred the rails session secret_token to the upgraded instance along with the entire database. I followed exactly this procedure in the past when upgrading from Redmine 1.2 to 1.3.1 and it worked perfectly. If I register a new account on our new upgraded Redmine instance and I go to my user account settings in gmail I see that there are two authorized applications for Redmine for the same URL.

It looks like the root of the problem is the openid.realm passed to the OpenID provider when authenticating. When the user is sent to Google, the url parameters has changed from:

openid.realm=http://our.domain.com/redmine/ openid.return_to=http://our.domain.com/redmine/login?_method%3Dpost%26open_id_complete%3D1

to:

openid.realm=http://our.domain.com openid.return_to=http://our.domain.com/redmine/login?_method%3Dpost

The realm doesn't contain the /redmine in the upgraded instance, after manually editing the browser URL I have established that adding this section will fix the problem. What can I can I do to get it to generate the correct openid.realm but still work in Passenger. Is relative root url handled at Apache level instead of rails level in Passenger?

Gems used: open_id_authentication, ruby-openid, rack-openid.

Regards, Pierre

Answer 1

Doesn't seem like there is a elegant solution. I monkey-patched the rack_openid gem to force the ream_url. Place this in an initializer somewhere:

class Rack::OpenID
  alias :super_realm_url :realm_url

  def realm_url(req)
    super_realm_url(req) + "/redmine/"
  end
end