-
Notifications
You must be signed in to change notification settings - Fork 176
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
can this work with selling-partner api? possibly related to ignored headers #121
Comments
Doubtful related to ignored headers – the Selling Partner API Models uses the official Java SDK client, which is where I got the ignored headers from in the first place (v2 of the API) It's a bit hard to debug without code – can you please show what you're trying? |
sp-api documentation shows that it is expecting user-agent to be included. https://github.com/amzn/selling-partner-api-docs/blob/main/guides/developer-guide/SellingPartnerApiDeveloperGuide.md#authorization-header (if that link doesn't go right to it, search for "Authorization header") My apologies, i meant to include that link in my original post and forgot. It's entirely possible that i'm completely mucking something up, I'm having a bit of a hard time with following the docs on it, they're a bit clunky, and jump all over the place. . . . and i'm also attempting to do something that's a bit .. perhaps unorthodox. I'm attempting to put together a module that uses swagger-client to dynamically generate an API, and then inject the proper headers and signing into it. I feel like I'm almost there, because last night when I was working on it, I had managed to work through several other errors, and finally landed on a "signature does not match" problem Here's my code
What I'm attempting to sign (and i'm not 100% positive this is all correct, but it seems to match with the sp-api documentation) looks like
this is what i get out of aws4:
... and lastly, this is what i get back from Amazon, with an error Forbidden 403:
Note that I'm not necessarily trying to make a request with meaningful results into the sp-api, right now i'm just trying to get a request successfully through TO any of the sp-api functions |
The error's not saying anything about a missing header – it's saying the signature isn't matching. I can't see where you're giving aws4 the |
right, and i have no idea what it's trying to sign versus what amazon's expecting it to sign. I guess I need to parse that out of the url? I'll give it a spin, thanks for the advice. Between the sp-api docs, and the docs for this, I have absolutely no idea what i'm trying to get to converge. :-S |
Try this: const https = require('https')
const aws4 = require('aws4')
let opts = {
service: 'execute-api',
host: 'sellingpartnerapi-na.amazon.com',
path: '/authorization/v1/authorizationCode?sellingPartnerId=1&developerId=1&mwsAuthToken=1',
headers: {
'x-amz-access-token': myLwaAccessToken,
'user-agent': 'sp-api-simple/0.1 (Language=JavaScript; Platform=Node)',
},
}
aws4.sign(opts)
https.request(opts, res => res.pipe(process.stdout)).end() |
yeah, i'm having a feeling that the Request object that swagger-client is wanting is .. different .. from the standard node request object. so just passing the incoming request through aws4 isn't going to work.. i think i need to do a bit of translation between them .. working that out. Thanks for your help!! Super appreciated. I also just realized looking at this thread that i'm not using Sandbox like I thought I was, so.. also helpful. |
It looks like it uses Which came a lot later than Node.js. Documented here: https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API They're probably using https://www.npmjs.com/package/node-fetch to get it to work in Node.js – it's not supported natively in Node.js yet, but will be soon. I have a fetch-compatible aws4 signer here: https://github.com/mhart/aws4fetch But it's more intended for environments that have fetch and subtle crypto (like browsers or Cloudflare workers). You could probably get it working with Node.js, but you'd need to pull in a bunch of modules. |
ok, so, i'm trying this, just converting the request from swagger-client into options palatable to aws4, then passing it to https, and then sleeping forever so that swagger doesn't end up triggering an error
output
in comparing this to the ps-api documentation, that documentation has |
The fact that you got the signing to work (only to have a My advice is to get it to work with plain old Node.js code first and then figure out what you need to translate your params to work with swagger-client. |
I do appreciate the help. That's what I'm working with right now, is just plain https module, and still slamming into InvalidSignature. I'll keep plugging at it, and if I come up with anything that might relate to this, i'll let you know. Thanks! |
Before you got an What's the result of this? const https = require('https')
const aws4 = require('aws4')
let opts = {
service: 'execute-api',
host: 'sellingpartnerapi-na.amazon.com',
path: '/authorization/v1/authorizationCode?sellingPartnerId=1&developerId=1&mwsAuthToken=1',
headers: {
'x-amz-access-token': 'Atza|Iw....................hKo23Bdf6vB',
'user-agent': 'sp-api-simple/0.1 (Language=JavaScript; Platform=Node)',
},
}
aws4.sign(opts)
https.request(opts, res => res.pipe(process.stdout)).end() |
Here's how I know the signing is working correctly: If I run the code above (with my credentials set in {
"errors": [
{
"message": "Access to requested resource is denied.",
"code": "Unauthorized",
"details": "The access token you provided is revoked, malformed or invalid."
}
]
} However, if I mess with the Authorization header, which is where the signing is happening, like this: aws4.sign(opts)
opts.headers.Authorization = opts.headers.Authorization.replace(/..$/, '00') Then I get an So the signature is validated before the access token is validated. And I can successfully get past the signature validation before I run into access token validation (because I'm not actually passing a valid access token) |
I get
|
You're literally copying and pasting the code from #121 (comment) into a file (say If so, I mean... I don't really know what to say. What Node.js version are you using? |
only other things i can come up with off the top, are maybe i'm using the entirely wrong thing for the secret and access key? or i've completely messed up my configuration in AWS somehow normally using node 15 in windows, but here's node 13 in wsl/linux
|
|
the source directory is under a package.json that has type: "module" set i can back it out, just a few moments to reset it to use require instead of import .. edit: results are same in same environments, regardless of using modules or not |
Yeah, only thing I can think would be your credentials then – most APIs are a little nicer with their errors if there's something wrong with the credentials, but this might be different. Try just with any old random (legitimate) AWS credentials – it won't matter if the credentials have access to the API or not (eg, I just used my credentials and I don't have access) – at least then you can get past the signature error. |
I think I discovered what the problem was, overall -- I had confused my LWA secret with my AWS secret. Too many secrets and access codes and things going around in this stuff. :-D I really, really appreciate your help with this. I am now down to
which means it at least accepts everything i sent it. :-D thank you, thank you |
fwiw, on top of all that, it turns out that the selling-partner-api documentation is basically completely broken -- it has you configure the access permissions in a way that requires additional methods to be called that it never once touches on. Seems the "how to setup" and "how to use" portions were quite possibly written independently of each other, and not in a compatible fashion. :-D |
I haven't quite yet figured out how to get a request signed by this through to work with SP-API, although I suspect it might be pretty close to it. If anyone knows a way to do it already, that'd be awesome, otherwise I think I'm going to do some poking around with this..
I do see this recent commit 1c5a4b6 that strips certain headers from the signing, but in the sp-api documentation, i see that it expects things like User-Agent to be included in the sign.
At the very least, I would think it would be useful to be able to configure any headers to be ignored, in the call to sign. I'm not sure if just making sure the headers signed in the example are the ones signed, will get us there. Amazon isn't exactly the best at telling us what we're doing wrong when we make an error. :-D
The text was updated successfully, but these errors were encountered: