https://netsuiteprofessionals.com logo
Join Slack
Powered by
Hi guys - I need a way to get around hard coding a...
# suitescript
w
Hi guys - I need a way to get around hard coding a JWT token in scheduled script code on Netsuite. Has anyone here done something like this before, and if so - how did you go about doing it?
s
by 'avoiding hard coding' are you trying to protect a static JWT or are you looking to dynamically retrieve a JWT?
w
I am looking to protect a static JWT which the scheduled script will need to use to authenticate with an amazon service
t
There are a lot of ways depending on the level of security your after.
b
NetSuite preferred way of sending passwords to external services is using a credential field to generate a GUID
The GUID is basically used in a template string by the https module
you can look at a basic example on the N/https Module help page
it is a pain to work with, but is very secure
w
@battk maybe I'm misunderstanding. I am basically looking to safely store this JWT token on Netsuite somehow. I was thinking I could store it in a custom record, but I don't like that very much. Hard coding is even worse. Would this method you are talking about help with this problem?
b
Yes. The password will not be visible to any user of your account
w
@battk Thanks, I found that example, but I don't think I fully understand what's going on here. Could you maybe explain what this is doing?
b
The suitelet creates a credential field
The credential field takes a password and returns a string that represents an id
When I had to use this api. I didnt use a suitelet. I had a custom record where I used a user event script too add a credential field and a client script to transfer the guid to a custom field
Depending on your case you may just want to use the suitelet to generate a guid and hardcode the guid in your script
w
I see, so this GUID can be sent to the suitelet to get the original password back?
t
If it isn’t about security you can just add a parameter to the script record and set it on the deployment record. This keeps it out of you script file.
w
It is about security, just making that JWT token as inaccessible as possible on Netsuite
t
Then the GUID is definitely the way to go.
w
I don't understand how this GUID is helping me. I need the original JWT token each time the scheduled script runs. So if I hard code this GUID on my scheduled script, am I able to just call a suitelet, pass it this GUID, and get my JWT token back?
b
The guid is an id that the https module replaces with your password
You will never be able to get access to the jwt token from netsuite. Only the guid
If you need to use the jwt token in crypto. You use netsuites crypto module
When i was figuring this out I just imagined Netsuite replacing instances of the guid with the credential before it sends the http request
Its why the credential is a pain. You will never have direct access to the jwt token again. You only have a guid which netsuite will replace with code outside of your control
I still believe my first description of string template is how you want to imagine it
s
AFAIK, the 'GUID' mechanism in NS is primitive, and can only be used for specific cases (e.g. setting an Auth header on an outbound request. It doesn't give us a generalized secure storage mechanism which is what @Will Schoenhals needs.
b
It can't really be used as a storage mechanism since you can't get its value ever again. It only allows you to code ways to use the credential. The SecureString mechanism allows setting headers, urls or body of https request. All in inconvenient ways that essentially require you to understand the crypto mechanism used by the webservice
s
Ah, I didn't know you could choose header/querystring/body with 
SecureString
. Maybe it's a bit more useful than I thought 🙂
5 Views
Open in Slack
PreviousNext
Powered by