Since outage over the past few days oauth appears to be broken. When user logs in and sends code and state back to redirect url all we end up with in UI is just error message “0, message=‘Attempt to decode JSON with unexpected mimetype: text/html; charset=utf-8’, url=URL(‘${authorization_url}’)” .
There was no issues before the outage but now it’s just broken.
Noteable dev here, we are seeing similar things with OAuth-enabled “legacy” plugins not working. The first step in the OAuth flow (redirecting user to auth provider) goes smoothly, then the token exchange fails.
In browser network logs, I see a GET to https://chat.openai.com/backend-api/aip/p/plugin-179013de-6465-4e36-8bbd-49e36767e91c/user-settings/oauth/callback has a 500 with payload {"detail":"Error in oauth callback"}. However on our backend I see the token exchange endpoint gave a status 200 with a valid access token / refresh token.
Based on the comment in How to Migrate from ChatGPT Plugins to Actions: Solving OAuth Failures that the new GPT OAuth hard-codes content-type url-form-encoded instead of being set in the ai-plugin.json manifest file (which is application/json for us at Noteable), I’m wondering if the OAuth client code on the OpenAI side is also now hard-coding that content-type for legacy plugins? That is to say, we’re returning JSON in the token exchange like always but OpenAI is failing to parse it?
It appears that it expects something else. It fails in the same fashion with the same error in legacy plugin and GPT actions as well. After error is presented to the user no further calls are made to authorization_url.
Got legacy plugins working again. It appears that changes over the past couple of days introduced new IP ranges as per ip-egress-ranges and after adding new range legacy plugin managed to be authed correctly and can interact with the service again also ensure your service handles urlencoded POST requests from ChatGPT as content type is now application/x-www-form-urlencoded not JSON.
GPTs auth works as well after GPT has been deleted and recreated from scratch with addition of new ip-egress-ranges and handling of urlencoded POST
The issue is still not resolved for our plugin. We are already using the “authorization_content_type”: “application/x-www-form-urlencoded” and never had any issues. New range of IPs are also white listed .
Call back response is {“detail”:“Error in oauth callback”}
Update: We no longer face any issue with authorization flow. No code/config change was done from our end.