Hey All: I am working on SHA256'ing an integration that utilizes GET calls to the RESTful endpoints. I have the POST working, but the GET is showing invalid signature. When comparing to a successful Postman call, everything is the same, so I am led to believe it is in the URL base string. Can anyone share a sanitized base string for a GET with URL params? TIA!

The base string for GET should be identical to POST, and both of them will have at least two URL params, script and deploy, which should also match. The GET call will usually have additional URL params, though, in addition to the two required params. What are you using to create the signature? Your own custom code or an existing OAuth library?

@scottvonduhn Thanks for the feedback. I'm not using a Suitelet end point, but rather a NetSuite native REST end point. So my URL is: <https://[realm].suitetalk.api.netsuite.com/services/rest/record/v1/shipitem?q=itemId+IS+>"FEDEX+SAVER" I am using hmac, urllib, & hashlib in Python.

Oh, REST web services, I was assuming Restlets. I suppose they are both RESTful, in their own ways. Restlets can very easily exceed REST principles, though.

I understand, and totally agree. This particular integration was built when I was brand new to the world of NetSuite and didn't know Restlets / Suitelets, etc... I have a note into the client to update their processes.

Was this integration already previously working with HMAC-SHA1? If so, changing the encryption and signature method should be sufficient, and nothing else should change. Just to rule out some unintended side-effect of the changes, though, I'd probably try to create a small test script in your preferred language to hit the GET and POST endpoints. You said you are able to get both via Postman, correct?

Yes, and I can hit the POST Endpoint without issue. Hitting the 'GET' though is failing. Using the same exact encoding/encryption as the POST.

and, I presume, the HMAC-SHA1 GET also works ?

yes. It is currently in production using SHA1

Yeah, that is honestly going to be tough to pin down. Often, I will use Postman or some known working tool to generate a signature for a valid call, then take a copy of the code and use the same values (hard-coding the nonce and timestamp to match) and verify that I can generate the identical signature string. Obviously, the call will fail that way, because the nonce is repeated, but you can at least verify that the signature generation is working.

Yeah, I did that, too 🙂 The values all matched, so I feel like it's got to be in the URL, figured if I could see a base string for a GET then maybe I could compare mine and see if that's where the issue is.

Is your issue resolved? I am encountering the same error for restlets. I am doing in python using different libraries. But can' get it to work. Has anyone else done that before in python ?

No, unfortunately. I'm pushing my client to move toward the Restlet and away from the REST endpoints.

my recommendation is to always to at least try a library first

Thanks @battk I will definitely look into that particular library

my response was more aimed at @tuli

Ah, sorry. I'll give it a shot, just curious why my script works ok with POST requests but fails with invalid signature on the GET requests.

you are probably correct in that its related to the base string construction

ok, I had tried both escaping and unescaping the double quotation marks, but that didn't seem to fix the issue. Will definitely look deeper into that when I have the opportunity.

thats not whats escaped in that parameter

@Alli Deacon @tuli here's an example with requests-oauthlib https://gist.github.com/michoelchaikin/100a569343a013c7181800f5325c5501

@michoel Thanks!

Thanks @michoel and @battk for your help, that example and those libraries made it really simple to do that.