1

I have a custom OAuth2 strategy in my application which I'm using with Omniauth to authorize users from several sites. (These sites are all different installations of the same application, also maintained in-house here, so I have access to both sides of the authorization.)

Rather than set up a new strategy for each site, we're using the request phase of the Omniauth cycle to update the strategy with e.g. a new client_secret and client_options at request time. We can distinguish between the sites using a parameter in the request, and this works when we're referring users to the remote login page.

However, the token request step seems to collapse. When I'm running development locally, with my app on port 3000 and the IDP on port 9000, everything works fine. On the staging server, I get a lot of

Faraday::Error::ConnectionFailed: Connection refused - connect(2)

I updated the omniauth-oauth2 gem to get the recent changes catching those errors, and now I just get

Could not authenticate you from [strategy] because "Failed to connect".

...which just means the same error is getting caught and output differently.

The stack trace suggests to me that this is happening in the request for the token. 'Failed to connect' makes me think this is a badly configured URL in the request. This is working locally (apparently). How can I debug on staging and figure out what's going wrong? I feel like I can't even figure out what I should be looking for, and where.

ETA: Watching the application logs on both sides, I can see that the IDP application never receives the request for the token; it redirects back to the callback in the client app, then doesn't see anything more. The client app has these unhelpful logs:

Started GET "/users/auth/[strategy]/callback?code=[code here]&response_type=code&state=[state here]" for [IP Address] at 2013-12-20 20:55:46 +0000
Processing by Users::OmniauthCallbacksController#failure as HTML

...whereas on localhost, where this works, the corresponding log looks like this:

Started GET "/users/auth/[strategy]/callback?code=[code here]&response_type=code&state=[state here]" for 127.0.0.1 at 2013-12-20 11:27:46 -0500
Processing by Users::OmniauthCallbacksController#[strategy] as HTML

So something's happening in the callback resulting in entering the failure action. The fact that the IDP never sees the token request makes me think somehow that request is getting built incorrectly; how can I find it and see it before it gets sent?

UPDATE: As you'll see from the comments, I'm 99% certain this is not the SSL certificates problem. I should add that on the production site, OAuth is working fine; the difference between staging and production is the changes mentioned above (second paragraph) to handle multiple sites with the same strategy.

Community
  • 1
  • 1
pjmorse
  • 9,204
  • 9
  • 54
  • 124
  • Hi, I've found that `Faraday::Error::ConnectionFailed` always implies an `SSL_connect` error. The reason why your staging server can't receive requests is maybe about your certificate configuration. Hope [this](http://stackoverflow.com/questions/10775640/omniauth-facebook-error-faradayerrorconnectionfailed) may help. – ifyouseewendy Dec 28 '13 at 18:40
  • That's a good lead, thanks. I didn't think our servers were forcing SSL (shhhh) but it's possible they are and I didn't know, so I will check on that. (If it works, post this as an answer so I can make sure you get the bounty?) – pjmorse Dec 28 '13 at 19:58
  • I'm glad this may help, and hope you can work out the problem finally. – ifyouseewendy Dec 30 '13 at 03:57
  • The staging server is Ubuntu. I ran the OpenSSL update and got `OpenSSL 1.0.1 14 Mar 2012` from `openssl version` which I think means we're up to date. I restarted Apache (and thus the Passenger-based Rails app)... and it still doesn't work. Also, I've verified that the IDP isn't listening for https. – pjmorse Dec 30 '13 at 14:24
  • pjmorse did you find a solution for this ? – fanta Aug 13 '15 at 15:15
  • @fanta thanks for asking - I'm no longer with the company, as of about a year and a half ago, so I'm not sure how they solved the problem, but from the activity on the git repo it seems likely that they did. – pjmorse Aug 14 '15 at 14:27
  • Thanks @pjmorse, I was having the same problem. Turned out to be a missing nginx configuration on the servers. – fanta Aug 14 '15 at 15:07

0 Answers0