Hi there,
I’m brand new to Celigo, so bear with me! I have a GraphQL application I’m trying to integrate with; it requires an access token from our OAuth 2.0 provider.
I have an iClient set up for OAuth 2.0, and I’m using it successfully with an HTTP Connection, but I’m having trouble getting it set up with GraphQL. I believe that problem may be that GraphQL typically returns a 200 response (even in the case of error), and Celigo doesn’t attempt to authenticate unless it receives a 401 response on the initial request.
I’ve tried using the “Non-standard API response patterns” configuration in my GraphQL Connection to account for this, but it still doesn’t appear to be detecting the authentication failure.
Here’s the response body that GraphQL is sending when no access token is provided:
{
"errors": [
{
"message": "The current user is not authorized to access this resource.",
"locations": [
{
"line": 2,
"column": 3
}
],
"path": [
"salesOrders"
],
"extensions": {
"code": "AUTH_NOT_AUTHORIZED"
}
}
],
"data": {
"salesOrders": null
}
}
…and here are the “Non-standard API response patterns” settings I have set up in my GraphQL Connection:
If somebody could point me in the right direction, I’d appreciate it! Thanks!
Welcome! Could you try not putting anything in "Override HTTP status code for auth errors", and changing your path to errors.0.extensions.code?
I made that change, but sadly no luck:
I also tried changing the path and setting the HTTP status code back to 200, same result.
Hmm, that should work if that's the response being returned. What if you remove the value for "Override auth error values"?
How this section is supposed to work is like this:
- We first check if you have something specified for status code override. If you do, then we check if the status code returned matches the status code you specified, and if it does, then we recognize it as an error. So for this, we don't look at the fail path.
- If, after checking the status code, we still haven't identified an error, we check the fail path. If there is something in that fail path, then it should be marked as a failure.
- Lastly, if you also have error values specified, then we check that the value in that path matches the value you specified.
Strange – when I run the Flow, it appears that it does detect the authentication failure and attempt to obtain an access token. It’s still not working, but that’s a problem for tomorrow.
But when I click the Preview button while editing the GraphQL export in my Flow (which is what I’ve been doing to test), it doesn’t appear to attempt to authenticate. Should I not expect the Preview button to use the configured authentication settings?
If you enable debug on the export and/or connection, you don't see if making the subsequent call? I would expect it to work in preview.
I didn’t know you could debug an Export – I couldn’t find a menu option for it.
But for the Connection, now I’m really confused. I only see one call in the debug log, but in my own application logs I do see it attempting to obtain an access token…strangely, it’s attempting to use the wrong iClient. It’s like it’s using an older version of the Connection somehow.
Let me revisit my config and make sure I have my house in order before I bug you more than I already have. I really appreciate the help!
Okay, figured out what I was looking at. Sorry for the wild goose chase – what I was seeing was noise from a subsequent step in my Flow that I had forgotten about.
It appears that my GraphQL Export is still not attempting to authenticate under any circumstances.
Edit: I did remove the value from "Override auth error values", but no change.
I’d probably open a ticket at this point so engineering can take a look.
Will do, thanks for your help!
