Anyway, I am trying to connect Glide with a Netsuite API. Netsuite’s token based authentication is based on OAuth 1.0; is there a (secure) way to generate a signed Authorization header so that I can successfully use Glide’s Call API action to work with Netsuite?
My use case is a bit different - I don’t need (or want) the user to authenticate with Netsuite, I just need Glide to be able to create a signed OAuth 1.0 header so I can POST a JSON into Netsuite based on a record in Glide. Pathfix is a no-go since it looks like they only support pre-defined services anyway.
I think it would be difficult to create a signature externally and somehow pass that back into Glide securely.
Of course I can continue using Zapier for this use case, the idea was to make it more secure and be able to get a response back from the endpoint directly into Glide.
I’m not familiar with Netsuite’s API to help out more, sorry. You may be able to use a template column to create the header. You could then use parts of the output in a Call API column. It may take a bit of creative thinking to get it to work in Glide without an external tool like Make to assist.
I got this working and wanted to document here for anyone who might stumble across this later. I was able to generate and correctly sign an OAuth 1.0 header using a combination of templates, encode text, and JavaScript.
Major caveat, this is not secure. I understand that Glide executes Javascript locally and my code contains the private consumer and token secrets. I am comfortable with this for my use case as this is internal only and I have taken mitigating steps within the endpoint application.
After gathering keys, URLs, etc., into a helper table I created all the components of the OAuth 1.0 header and base string using template columns.
Format Date column to get a Unix timestamp
Javascript code to create the random nonce value.
Encode text to encode all the strings, values and URLs to percent-encoding
The signing was the missing piece - found this code snippet in this thread after trying a bunch of other things that didn’t work for various reasons.
There was a LOT of trial and error to finally get this to work, but it’s up and running now! Thanks @Rev for taking the time and pointing me in a direction which ultimately led to this solution.
I would love to see support for OAuth 1.0 and 2.0 in the Call API action - I think there would be a ton of value there.