0

We have a web application with Google calendar API using OAuth 2.0 client IDs. The problem is that it works well with the Test app: http://test.our-domain.com

BUT it doesn't work in the production that has SSL.: https://app.ourdomain.com

Both are on the same server and on the same domain, Both are authorized in the Credentials page as http://test.our-domain.com/callback and https://app.ourdomain.com/callback

When the user sign in it looks like the process is OK but the Token does not being saved.

Here is the error we have on the production log - Please help...

2017-11-23 22:49:56,656 [ 33] ERROR DotNetOpenAuth.Http - WebException from https://accounts.google.com/o/oauth2/token: { "error" : "redirect_uri_mismatch" }

2017-11-23 22:49:56,656 [ 33] ERROR Client.Management.UserCalendarEntryController
- Failed to get google authenticator for XXXXXXXXXXXXXXXXXX Blockquote

yair
  • 1
  • 1
  • Try creating a new credentials for the production server. It is a [best practice](https://developers.google.com/identity/protocols/OAuth2#scenarios) that the client credentials for prod/test/staging are different. It also takes sometime before the changes actually reflect. Hope this helps – Mr.Rebot Nov 24 '17 at 16:13
  • Thanks! Both are on the same server but with different sub domain. One is working well and the one with https doesn't work. Do you think it will help? – yair Nov 25 '17 at 21:57

2 Answers2

0

As referred with this thread, the redirect URI (where the response is returned to) has to be registered in the APIs console, and the error is indicating that you haven't done that, or haven't done it correctly.

Go to the console for your project and look under API Access. You should see your client ID & secret there, along with a list of redirect URIs. If the URI you want isn't listed, click edit settings and add the URI to the list.

Also, be noted that updating the google api console can take some time. Generally only a few minutes but sometimes it seems longer.

abielita
  • 13,147
  • 2
  • 17
  • 59
  • Hi Thanks! That looks OK in our consul. Both sub domains are authorized on the " OAuth 2.0 client IDs". As I wrote, we have a specific problem only with the sub domain the has SSL (https). Any ideas? – yair Nov 25 '17 at 21:49
-1

(I found your post on xplace, I don't have an account there) - I can help you debug the issue if you'd like. feel free to leave your email and I'll reach out.

ariel
  • 1