@svonduhn thanks for this PR!

GET from works good for me, but I didn't manage to get POST request to work. For example,/record/v1/customer with body parameters. I see "invalid signature" in Audit, but have no idea what exactly went wrong in a signature process

Is there any change you have an example on how to compose a POST request with body parameters?

Thanks!

@zarkone Our account does not have the REST web services feature enabled, so I can only test with Restlets. However, I was able to make POST and PUT calls to a RESTlet just fine, using a JSON payload (request body), by calling setPayload with a request body.

    final OAuthRequest request = new OAuthRequest(Verb.POST, PROTECTED_RESOURCE_URL);    request.setRealm(ACCOUNT_ID);    service.signRequest(accessToken, request);    request.addHeader("Content-Type", "application/json");    request.setPayload("[{\"a\":1},{\"b\":false}]");

The Realm still must be set before signing the request, as it is part of the Authorization header, even though it is not used in the signature itself.

It's possible you may need to set some additional headers when sending a payload body for REST web service that Restlets don't require. Do you have access to any RESTlets to test that?

If not, you can use this Echo RESTlet that will send back any GET, PUT, or POST request with the following code:

/** @NScriptType restlet* @NApiVersion 2.1*/define(() => { let echo = body => body; return { get: echo, put: echo, post: echo } })

Let me know if that works.

@svonduhn thanks for your reply!

I get it to work, but the issue was that I've added body parameters to signature. It was a stupid mistake, but for some reason I decided that it is a good idea back then (and forgot about it). "Some reason" could be that because of Netsuite doesn't requirebody_hash to be added to signature, I assumed that I need to add body params...

This also means that the signature would be the same for different body, if I understand everything correct.

@zarkone Apart from the fact that the nonce and timestamp will be different for each call, the other parameters will essentially always be the same for any POST or PUT call, regardless of what is in the body/payload. But the two non-static values will still cause the signature to change each time anyway.

Hello guys, thank you for this contribution! Any update on this Pull Request? I would like to use the new Signature Service as part of my implementation.

As of this week our Netsuite integration no longer works due to not using SHA1, so I guess they've started rolling out SHA256 only.

I guess I'll be forking and building a local copy.

Does anyone have any tips on building it locally, when I try I get this duringmvn compile:

Could not resolve dependencies for project com.github.scribejava:scribejava-core:jar:8.3.2-SNAPSHOT: com.github.scribejava:scribejava-java8:jar:8.3.2-SNAPSHOT was not found in https://oss.sonatype.org/content/repositories/snapshots

The sandbox environment only supports HMAC-SHA256 starting from the 30th of July.

The end of support for HMACSHA1 in production is expected by the middle of August. It's still not clear to me if they already supports HMAC-SHA256 in production and can (temporarily) use both algo until the dismission of HMAC-SHA1.

@andynormancx trymvn install instead.

Alternatively, you can just use the latest published version of scribejava, 8.3.1, then add copies of the HMACSha256SignatureService and NetSuiteApi classes directly to your project.

@natzei You can definitely use HMAC-SHA256 right now. You do not need to wait for HMAC-SHA1 to be deprecated.

Thanks this was a huge help. My SB has required HMAC256, like mentioned earlier, since Jul 30. My production environment has not followed suit yet, but it looks like they roll out thru October.

Hey guys,
any chance to get this merged?

Hi there,
Any chance of this being merged? Looks like a nice addition, and it would make Scribe a very nice option for all those integration designing companies ;)

BTW I can confirm it works with restlets in the latest NetSuite 24.1 version

Works good, tested on Netsuite 2024.2. Nice addition, you should merge it.