RE: Issues Generating a REST Web Services Signature

Anyone have any insight into creating the signature for a REST API SuiteQL signature?  I have one for authenticating and calling a RESTlet script, and it works just fine in my app, but when I try to call the REST API for a SuiteQL query, I keep getting signature errors.

Guessing I must be missing something obvious.  Changing the URLs to the SuiteQL ones keeps returning me error: “error=”token_rejected”, error_description=”Invalid login attempt.””…  But my TBA credentials work perfectly fine with a RESTlet URL instead…

I’m generating my signature using Crypto JS.

CharlesBastian Rookie Asked on December 9, 2020 in SuiteTalk.
Add Comment
4 Answers

Seeing similar oddities here now in Aug 2023.

Everything is fixed here in our outgoing requests, except obviously TIMESTAMP and OTP (changes every 30 secs).  All else remains untouched.  Yet, pressing F5/reload bunches of times (and watching audit logs inside NS UI) causes ~50% successful login, 50% failed login.  This erratic flip-flop behavior persists not matter the client, no matter the source network, no matter the time-of-day, etc.

google DNS returns 2 different IP addresses for our (and also for our lookups — curiously, the two FQDNs share one IP and each also has its own separate/different IP address.  I thought this might indicate a caching / akamai issue, but DNS spoofing everything locally to the one final/single IP (tried the shared IP and also each pointing to its own unique IP) did not cause the 100% go or else 100% no-go that was expected but instead kept right on returning ~50% go/no-go.  This seems to indicate an unobvious cause invisible to us lowlings  Right now NS feels a lot like dealing with Microsoft, where everything was right per the documentational-majority, but yet the things were still constantly gaslighting, causing a resort to reboot-until-it-works-then-do-not-reboot-it-!!! approach / comic routine to “problem solving”.

Quite maddening.  I realize this is only a small, visible part of what’s possibly going on behind their green curtains — akamai and/or NS may be doing all kinds of internal shenanigans.  For instance, I routinely see in the login audit log (for restlets, rest ws, etc) private (10.x.y.z) IP addresses sprinkled amongst the public IPs, indicating scripts/bundles/apps/etc living on different servers hidden behind a special ‘sometimes-NAT”.

I’m wondering if this may all be part of some kind of accidental or maybe even intentional sabotage…the ‘paying partners’ may get a single fixed-server (the better to bill them space/transfer for) instead of the (apparent/presumed?) hodge-podge loose in our not-a-paying-partner/freelance/”consultants”wild.

I find it incredible that a multi-billion-dollar company has the most dreadful system, and far more dreadful “documentation”.

I’ve been programming for several decades, and this NetSuite monster is among the Very Worst.

Dealing with NetSuite has hurt my image and reputation to clients.

Rookie Answered on August 10, 2023.
Add Comment

Your Answer

By posting your answer, you agree to the privacy policy and terms of service.