During recent development of an integration servic...
# suitetalkapi
m
During recent development of an integration service, we have discovered that invalid REST payloads to NetSuite trigger a 401 Unauthorized response from NS, with only the message "Invalid Login. Check the Login Audit Trail". Doing so gives "NonceUsed" as the error (although our auth code has been working for months). Making the same post to the REST API using the Postman collection from NetSuite gets a much better 400 Bad Request response with informative error_details in the content. I had suspected that our change to HMAC-SHA256 last fall might have something to do with this, but it appears the Postman collection is also using HMAC-SHA256. Has anyone else seen this, or perhaps have some insight? And by "invalid JSON", I mean something as simple as using a non-existent ID for the Parent field of a new Customer record.
b
the nonce represents a unique number assigned to each request
usually random
your error suggests that whatever you are using to generate the authorization header is not good enough to generate unique nonces
m
Yes, it does suggest that. But I have no problems with the nonce when the payload is something that NetSuite accepts. It only fails when there is an issue with the JSON. Have not seen rhyme nor reason yet on why it is happening.
b
you would need to start logging your nonces
m
Yes that's a good suggestion. I have been discounting the error msg from NS as inaccurate, but good chance it's telling me the problem and I'm not listening.
Logging shows a new nonce for each call to NS. In testing, one call to the /customer endpoint succeeds, the next call to the same endpoint (new nonce, timestamp, signature, etc.) with a different payload fails. I remember chasing my tail on this 5 weeks ago. NS only says it's a login failure when NS doesn't like the JSON payload
b
i personally have never seen what you are describing, so you may want to give netsuite support something easily reproducible so that they can reproduce it themselves
m
@battk You were right of course. I thought I had disabled a redelivery method during development. It was still hooked in, and not properly resetting the auth signature. Thanks for your input!