request to netsuite RESTlets response Invalid Login Attemp-Invalid Signature
I am accessing a RESTlets resource in netsuite via Token Based Authentication (TBA).
When I send my request in postman, the resource responds OK Status 200.
But when I want to access from my Apex code (Salesforce).
response Invalid Login attempting Status 403.
and in netsuite it shows invalid signature.
I think it is due to the encode but I changed this and it still does not work.
Can someone help me please.
It is a huge pain writing these things without starting from a working implementation. Im not sure if you can find OAuth for Apex, but you probably want to start at least at a java implementation like Signpost. Troubleshoot Token-based Authentication (TBA) is the best NetSuite specific resource.
I can start listing things that I see wrong, but no promises that I see them all
- The realm is not used as a parameter for the base string. you should add it to your oauth parameters after you have generated the base string.
- You need to percent encode your oauth parameters while generating the header. You won’t need to for the keys, since they dont have reserved characters, you do need to do it for the values. Importantly, this will mean that your signature will be percent encoded.
- While restlets dont accept form posts, you still need to get the query parameters from the url to be used as parameters for your base string. Same for all the other methods restlets accept
- Although I don’t think its an issue for your inputs, you are supposed to lowercase the url’s scheme and hostname.
- You need to percent encode both the key and the value of the parameters while generating the request parameters (your s String). This is complicated in that you preemptively percent encode your decoded url query parameters, I heavily recommend you do not do this.
- You probably also want to make sure your percent encoding is correct. The percent encoding you will be doing thorughout uses %20 for spaces instead of +. Some encoding utilities use percent encoding as used in form posts, which uses + for spaces.
For extra emphasis, you will be percent encoding in 4 different places. Twice in your base string: once while generating your request parameters key and values, and again while combining the method, uri, and the request parameters. This will mean that your request parameters will be percent encoded twice. The third time you do percent encoding will be while generating the parameters used for the header. Fourth is for your consumer secret and token secret, though it is unnecessary the vast majority of the time, nobody generates unfriendly secrets