Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Error authenticating /auth/failure?message=invalid_response #249

erskingardner opened this Issue Apr 1, 2011 · 27 comments


None yet

I'm getting an error trying to sign on with Facebook/Twitter that just started yesterday out of the blue. I can't seem to find anything that I would have caused it (checked the gemfile for updated gems there aren't any; checked all my authorization methods, haven't changed).

I've tried to debug it but I can't figure out where in the process this error would be coming from. Looking in the omniauth code it looks like the invalid_response comes from a json error in the response from the authenticator.

Anyone else seeing this?!

Me too, exactly the same problem, but not in local, that's really weird...

Just a quick update here, I just fixed this issue but upgrading from ree1.8.7 to 1.9.2. Not sure why this would have fixed it but hey, not going to complain.

You GENIUS man !
Thank you so much !

michiels commented Apr 6, 2011

Was searching for this. Having this error with GitHub provider. I'm on 1.9.2 but doesn't work yet. Any updates?

are you sure you are on 1.9.2 on all your environments ? My problem was because on local I was on 1.9.2 and in heroku I was on ree

same problem running on local with ruby 1.9.2p0 and ruby 1.9.2p180 also.

EDIT: sorry, was typo error. Its working.

cool !

same problem running on local with ruby 1.9.2p180

jyn commented Apr 29, 2011

I had a similar problem but only on Heroku. Heroku was running ree 1.8.7 and I was running 1.8.7 locally. I was also trying to authenticate against Google. Locally, everything worked fine. But on Heroku, authentication would get through the provider and on the callback, it would then redirect back to the /auth/failure?message=invalid_response endpoint, thus pointing to some failure in OmniAuth (as my callback action was never invoked - which I assume is because OmniAuth rack middleware is intercepting the call, attempting to process the request and bombing out)

Heroku logs didn't show anything. Since this is OAuth, I assume that it also doesn't seem to be the same kind of issue that the openID guys faced (can't write to the /tmp directory).

The first thing I tried was to make sure that a JSON parser implementation (supported by MultiJSON) is included in the Gemfile. This problem got me in the past and if MultiJSON doesn't detect a JSON parser, things can get a bit problematic. So I included 'json_pure'. Unfortunately this did not fix the Heroku problem.

As of yesterday, I upgraded the app to 1.9.2 and changed the Heroku platform to use mri 1.9.2 and I can happily report that everything works fine. I can now authenticate without any issue.

So from my experience, it looks like you may need to do the following:

  • Upgrade to 1.9.2
  • Make sure a supported JSON parser (from MultiJSON) implementation is included in your Gemfile

It helps!

I'm still getting this on 1.9.2 in Rails 3.1 as well. Requiring MultiJSON hasn't helped at all.

@robomay - I got it to work - at least in 3.0.9 - by forcing omniauth version 0.2.0. Update your gemfile to gem 'omniauth', '0.2.0' and run bundle install. I didn't bother specifying any additional gems for json.

Hope this works.

I've the same error on rails 3.0.9 on development environment, but I'm receiving only three parameters provider(twitter in my case), oauth_token and oauth_verifier, and my question is and the uid parameter? .

for OLD versions of omniAuth :
render :text => request.env["rack.auth"].to_yaml (debug tool or method to see return of twitter in my case)
MY SOLUTION:(railscasts episodes 235/236)
for new versions of omniAuth :
render :text=>request.env["omniauth.auth"].to_yaml ( information about my twitter user)

@bsodmike Unfortunately I can't use that version due to a conflict with the multi_json requirement and sass-rails in 3.1.

I'm having the same issues. They are occurring in 1.8.7 and 1.9.2 for me. Rails 3.0.9

excid3 commented Jul 11, 2011

The fix for me was changing rack.auth to omniauth.auth like @MrFerrys mentioned. This was the problem I was experiencing with making Omnisocial Rails 3.1 compatible => https://github.com/icelab/omnisocial/pull/26


this would work fine :)

def create auth = request.env["omniauth.auth"]
render :text => auth.to_xml

I had the same issue, however, the cause was my method in the authentications controller for create was wrong.
The elsif current_user statement wasn't saving the current_user.authentications. Not sure about all the background methods, but makings sure the line read like the following solved the issue.

  current_user.authentications.create!(:provider => omniauth['provider'], :uid => omniauth['uid'])

I have the same problem as @robotmay

Requiring MultiJSON (pure_json 1.6.1) hasn't helped at all on Heroku (rails3 on cedar stack)

I still get the invalid_response failure when omniauth is trying to authenticate to twitter.

Any luck on this? (This is my first experience with rails).

I have the same problem: http://localhost:3000/auth/failure?message=invalid_response

The page says:
Routing Error

No route matches [GET] "/auth/failure"

  • The JSON pure fix does not help.
  • Running 1.9.2 already / Rails 3.1.
  • @rajibahmed's solution does not work
  • Already using omniauth.auth (Railscast 241)

Any progress on this? Like @andycasey, this is my first experience with Rails.

So apropos my previous post, it seems twitter have changed their api calls. Try this:

def self.create_with_omniauth(auth)
    create! do |user|
        user.provider = auth["provider"]
        user.uid = auth["uid"]
        user.name = auth["info"]["name"]

I am also seeing this issue


Rails 3.1.0
omniauth 1.0.1
omniauth-oauth 1.0.0
omniauth-oauth2 1.0.0
omniauth-twitter 0.0.7

on ruby-1.9.2-p180

if I log request.env["omniauth.auth"], I can see my response from Twitter, but I'm still getting a 500 'invalid_response' error.

I tried explicitly adding a JSON parser to my gem file to no avail.

Any other troubleshooting ideas?

Hi @technicolorenvy,

I revisited this problem last night. I originally had the problem on Heroku using a cedar stack, but now I am running on a bamboo-mri-1.9.2 stack. To fix the 'invalid_response' routing problem I added

:omniauth_callbacks => 'authentications'

to my devise_for routing, such that my config/routes.rb file contains this line:

devise_for :users, :controllers => { :omniauth_callbacks => 'authentications', :registrations => 'registrations' }

I did have some other minor issues along the way, so if you still encounter problems let me know - I managed to get it all working in the early hours of the morning.

Hey @andycasey, thanks for the feedback.

I'm running w/out devise as I don't really need folk to login, per se. I more need them to grant me access to their twitter user's location, username, etc, etc.

i'm less concerned with the routing issue (I'll fix that when the time comes) and more perplexed with the fact that I'm getting the auth failure to begin with. Research seems to point towards this issue stemming from a malformed JSON response w/in omniauth (or one the related omniauth gems).

any other useful obvious bits that I may be missing?

Ok, found my issue

i didn't realize that omniauth was throwing a invalid_response error if I had an error in my controller. This seems heavy-handed, but now I know.

ua741 commented Jan 18, 2012

I am also facing this issue with my app.
Using Rails 3.1.1 ,
ruby 1.9.2p290
Using oa-more (0.2.6)
Using oauth (0.4.5)
Using oauth2 (0.4.1)
Using oa-oauth (0.2.6)
Using twitter (1.6.0)
When I sign it using twitter, then the app redirects to give Error authenticating /auth/failure?message=invalid_response
but when I go back to homepage, it shows signed it. So, even when the credentials are valid, it is redirecting in a wrong way.
PS: I don't have any route set for /auth/failure at present.

jolim commented Feb 7, 2012

The issue is related to having an error in your controller code. Any mistake in session#create (or wherever you've routed /auth/:provider/callback) will cause this strange behavior. So look at your logs and see what's failing!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment