I migrated my plugin to GPT - here is what I have found with OAuth and OpenAPI

[goo]

Hi everyone, I just migrated my ChatGPT plugin to a custom GPT. I bumped into issues and I wish to share the knowledge with everyone here. My plugin is called Adzviser and it pulls data for marketers from sources such as Facebook (Meta) Ads, Google Ads, Instagram, Google Analytics, etc. This is the GPT link.

First and foremost: this is my current plugin openapi.yaml and ai-plugin.json; this is my migrated GPT openapi.json. Feel free to compare them

OAuth: this is not changed much. Except for

• client_url from ai-plugin.json is now mapped to Authorization URL in GPT
• authorization_url from ai-plugin.json is now mapped to Token URL in GPT
• Note that if you are including the oauth endpoint like how zapier does it, the API hostname, server url need to share the same root domain. But since mine are in different domains, the oauth url being at adzviser.com and my endpoints at copter.adzviser.com, I had to do so separately in the Authorization tab. Otherwise, a simple import will do.

Weird stuff noticed:

• when importing from your existing hosted openapi.yaml, you need to have https:// upfront. Otherwise it does not load correctly, for some reason.
  
• After you import your existing yaml, you need to “Save” it first. Don’t click on the pencil button because that will mess things up.
  
  If you want to not look at the imported json/yaml code but the formatted ui at the pencil button, do so after you have saved your imported script.

I have found out that the openapi requirement has become more stringent than that of plugin dev. That’s why I redid my openapi spec from yaml to json, added some fields and removed some. I used this tool to check what went wrong with my openapi spec (Swagger & OpenAPI Online Validator | Swagger Parser). It’s very good except for that it won’t recognize oauth fields. You can ignore it because it will pass by GPT.

In conclusion, this is not a couple minute migration as what OpenAI advertises. Prepare youself with at least a couple hours of "trial and error"ing. It is funky.

[TheHenrik]

Regarding OAuth, you say you “had to do so separately in the Authorization tab” regarding different root domains for the auth/token urls vs the API url. What do you mean by this?

I am stuck on the same issue. My authentication is provided by Azure AD B2C, making the auth/token urls something like “https://{b2cTenant}.b2clogin.com/…/token”. My API root domain is obviously something else, but I cannot figure out how to configure this correctly. Any pointers?

[goo]

Right. Have you tried filling it out manually in this UI and save? I was stuck at this for a couple hours and eventually I gave up working out oauth through the openapi spec but directly doing this thru the UI.

[TheHenrik]

Yes. I tried filling out this OAuth UI, that’s when it’s telling me that the root domains do not match:

I even tried generating an access token manually and filling that out by setting “Authentication” to “API Key” and selecting “Bearer”. That just gave me “Error saving draft” without any details.

I mean, the error states something correct, the Auth/Token URL is indeed a different root domain than the API hostname. But I cannot fathom that being a limitation? Aren’t many APIs secured by a third party authentication provider - making these root domains different by default?

---

The “Client Id” and “Client Secret” values you fill in there when “Authentication” is set to “OAuth”; that’s for running authentication with the Client Credentials Flow, right?

That’s how I have tried setting it up so far at least, and I have verified that the same Client Credential token request returns a valid token from Postman.

---

Also, you openapi spec that you got working when also configuring this Authentication: OAuth; is that the one you linked initially as “openapi.json” (I’m not allowed to insert links in comments yet apparently)?

And then you configured the authorize/token urls to something like “…ttp://adzviser.com/…/oauth/v2.0/token” and “…/authorize”?

[goo]

Re “limitation on auth/token urls’ root domain” - yes I agree. I think that might be the reason why solutions for plugin authentications such as pluginlab.ai has not updated us here since GPT rolled out. I think either this is a bug with openai on this, or this is something intentional that will carry on from now. Luckily, I have authentication solution hosted on my sub root domain. I don’t get why you get through this though with the error. I tried for an hour and it eventually worked. I vividly recall it was due to the fact that I manually added my token/auth url here like the following.

Re “client id” and “client secret” - you can set new ones here if you have access to your source code; you can also use the old ones that you gave to OpenAI when you submitted the plugin. Or you can choose to leave them blank if you don’t want to check for them during token exchange.

Not sure what you are asking about the last comment tho.

[TheHenrik]

Really hope (and think) it’s an internal OpenAI bug, it’s the only thing that makes sense in my mind. Both source code and the Azure AD B2C auth provider is mine, luckily. But I’ll never be able to get them under the same root domain

Looks like the server response from OpenAI when I click “Save” is “500: Internal Server Error” as well. I’ll just wait a bit and check if others have similar issues.

Thanks for replying. You basically answered the last comment as well with the screenshot.

[goo]

No problem. I hope that this is a glitch or a short term issue from OpenAI too, otherwise it won’t make much sense. Happy to help.

[CakeCrusher]

I ran into a similar issue and I just deleted the action and re-instantiated it and it started working . Not the first time I did that to resolve errors, with my actions, also had to do it when the action was not in sync with my openapi spec.

[goo]

It’s a hit or miss, depending on luck. Haha. I have been there!

[jbt]

@goo Thanks for sharing. I’m running into the same issue. I was able to script kiddie some json to reach out to youtubes API but then I tried to oauth through the UI and kept getting the same issue.

I was going to try to put something like this below where I have the JSON but it doesnt work:

{
“client_id”: “YOUR_CLIENT_ID”,
“client_secret”: “YOUR_CLIENT_SECRET”,
“code”: “AUTHORIZATION_CODE”,
“redirect_uri”: “YOUR_REDIRECT_URI”,
“grant_type”: “authorization_code”
}

Any thoughts?

[jbt]

I might have figured it out, i had to go to the google console and enable the scopes. Now i need to get the right scope links into the UI.

[goo]

Any updates after that? Have you figured it out yet?

[Lumpymage]

Yeah, I discovered after hours of scratching my head, that editing actions doesn’t always save correctly. So I keep a copy elsewhere that I edit as needed. And then I’ll delete the existing action then just create a new one.

I’m sure this isn’t the intent, but this is a workaround for now.

[CakeCrusher]

Did you get Oauth to work without any errors or warnings. In my case I get the warning “Couldn’t log in with plugin.” even though the token exchange executed successfully .

[AIdeveloper]

I have the same “Couldn’t log in with plugin” issue.

It happens only if you are making a brand new GPT. Those who are migrating the plugins to the GPTs are just getting lucky to hit the existing plugins without the problem.

It seems the “Connected accounts” concept of the new GPT architecture is messed up with the obsolete plugin platform.

I hope they fix the problem before the debut of the GPT Store at the end of the month.

If more people experience the problem, please confirm. The OpenAI people may see this bug report.

[tm111]

Getting the same issues as others here. “Internal Server Error” when it’s trying to save

[AIdeveloper]

Please re-test it.

The major problem has been fixed.

The remaining issue is usability related. Not a showstopper. After a successful OAuth login, you would see this. But, I think the black label “Sign in with…” should disappear by now. Carry on to punch your next prompt, then that label will disappear.

But, the prompt should get a response after a successful login. That would streamline the user experience.

[andrei3]

Have you found a solution to this problem?

[goo]

Are you referring to the “Internal Server Error” or “Couldn’t log in with plugin”? There are multiple problems here.

[andrei3]

Sorry, I meant the problem when the ‘sign in with’ button doesn’t disappear after a successful login. It’s frustrating as it interrupts the conversation and the user might think the app is not working.