Closed josephjclark closed 4 months ago
@taylordowns2000 @mtuchi I'm not really oauth-literate but I think this is right? Check the addAuth
function in utils
@taylordowns2000 access_token
is just what the salesforce client uses to add its own oath header. I could rename it to make them consistent, but I'm not really sure it matters. Also it'll start a snake_case argument
Ok, I see the discussions in the other threads (although I'm gonna quietly ignore the chatgpt response!)
I introduced token
just a couple of weeks ago in #540. It's new and probably unused and I'm happy to sneakily break that one patch release.
Just to be clear - the idea is that users get an oauth JSON object from whatever tool they want (including lightning), and they add that to their state (which obviously Lightning will do), and because the config aligns with the oath standard it'll Just Work :tm:
Just to be clear - the idea is that users get an oauth JSON object from whatever tool they want (including lightning), and they add that to their state (which obviously Lightning will do), and because the config aligns with the oath standard it'll Just Work ™️
Yes! Exactly.
state.configuration
per this spec.access_token
in Bearer
per this spec.@josephjclark , @elias-ba , @mtuchi , it won't always work, but looks like it will work for 90% of credentials created using our new standard OpenFn/Lightning OAuth2 client/credential creator.
For those edge cases, we'll need to build adaptors. (But hey, more adaptors?? That's not so bad either!)
Summary
This PR reads the
token
from the config object and adds it to anAuthorization: Bearer ${token}
header.Details
I think this is all that's needed? It should work with oath and I think most api key-style APIs. I don't know how much variance there is in the pattern, maybe we can add more flexibility later if needed.
Note that users can provide their own Authorization header in the request, so even if this doesn't work in all cases, there's an easy work around.
Issues
Closes #581