Follow-up on the HMAC-SHA1 deprecation: Has anyon...
# integrations
s
Follow-up on the HMAC-SHA1 deprecation: Has anyone been able to create a test endpoint that does NOT allow HMAC-SHA1 ? In one of our developer accounts we created a new Employee, new Role, new Integration, and new Access Token, and created a brand new Restlet that only allows the new Role. I just tried this again today. Despite doing all of that, the restlet can be called using Token-based authentication with either HMAC-SHA256 or HMAC-SHA1, in contradiction to what NetSuite’s release notes for the last release stated. I cannot figure out how to create an endpoint that won’t accept HMAC-SHA1 so that we can properly test our readiness. Has anyone figured out what is required?
b
basically if you used it before, you can continue using it now
if you were ahead of the curve (or you have a test drive account you didnt use much) you might have access to an account that only accepts sha-256
s
Well, that’s the thing, everything I created today was entirely new, except for the account itself. Unless you are saying it needs to be an account we never made web service calls to prior to 2021.1? Because that pretty much rules them all out in our case.
b
account level
basically you needed to swap to sha-256 early
s
Well, we would have if it was only a configuration change, but it’s not. Not a single Java OAuth 1.0 library has HMAC-SHA256 built-in that we found, and our long-used Jersey client makes it especially hard to add HMAC-SHA256 support (requires a dozen custom classes worth of code). Additionally, I was hoping that Netsuite would give us a way to create an endpoint that explicitly would not accept HMAC-SHA1, so we could test that our new code was working. For all we know, it could still be creating the signature using HMAC-SHA1, but since that still works, the calls are working, and giving us a false sense of security. In other words, we have no way of knowing, with any certainty, that it works at all prior to pushing the code to production and just praying that it works. It is that fact, not the required switch to HAMC-SHA256, that I have an issue with. Why doesn’t Netsuite give us the tools to control this, or at least test it appropriately?
We have, for better or worse, tested restlet calls in every one of our developer accounts, so they all seem to be accepting HMAC-SHA1, even for brand new integrations.
interestingly,, one developer accoutn we have was not used for over two years (last time in 2019), but even that accoutn still accepts HMA-SHA1.
c
CryptoJS supports 256 if you're still looking for a JS library that will handle it
s
Well, I found out that one of our business analysts still had her test drive account from 8 years ago and has been keeping it alive all this time (but not actually using it). Finally, a place we can test that only accepts HMAC-SAH256!
All of our JS, C#, and SF/Apex code is updated to SHA256. It’s just Java where things are really backwards in terms of having no OAuth 1.0 + SHA256 anywhere
I mean, I could probably write the signature generation code, in fact I offered to do that, but architecture here would rather use a library.