https://netsuiteprofessionals.com logo
Join Slack
Powered by
Can I not have a map/reduce script call a suitelet...
# suitescript
d
Can I not have a map/reduce script call a suitelet?
Copy code
url.resolveScript({
  scriptId: 'myScriptid',
  deploymentId: 'myDeploymentId'
  returnExternalUrl: true});
Getting a html response about: You are not allowed to navigate directly to this page.
b
What problem are you experiencing?
d
a html response is returned from the suitelet stating: "You are not allowed to navigate directly to this page."
however, this worked in both of our sandbox environments, so when we moved to production we were surprised to receive a different result
s
are permissions set the same for the suitelet on your production environment as sandbox?
d
yeah, besides the Log Level
is there a better way of a m/r script to invoke a suietlet besides 
url.resolveScript
?
b
url.resolveScript
does not invoke a Suitelet. It just generates the URL.
s
yes - burky is correct- I assumed you are invoking the suitelet separately in code not shown?
d
oh yes, you're correct, 
resolveScript
to get the url, and 
https.get({url: myurl})
s
is your suitelet set to run without login then?
d
It wasn't originally, but it is now, and that seems to have resolved it
however, doesn't that make the suitelet publicly available?
b
yes, its also why you generally dont want to call suitelets from map/reduce scripts
d
so maybe this suitelet should have been a restlet?
b
potentially
usually you just want to use the code from the suitelet in the map/reduce
if you convert your suitelet to a restlet, you are very close to just using the code in the map/reduce
d
yeah, so I originally made a little aws_cognito library to fetch an access token. one of my developers took that and wrapped it into a suitelet and was calling it from a 1.0 script.
now another developer took that suitelet and tried to use it in a 2.0 m/r script and that's when we started to notice issues.
they could easily just call the library js directly
b
that does not sound like something you want in a public suitelet
d
I think they wrapped it into a suitelet was to have 1 place to configure the app client id & secrets
no, nothing i want public
I get what they're thinking, why configure the app client/secret in every script parameter that uses the library, when you can create a single suitelet (or maybe restlet)
b
do the custom module / library
d
would there be a better place to configure those app client / secrets....? Maybe in a custom record, and the secret could be encrypted?
b
share among all your scripts
d
could/should I have a config json file in the filecabinet with those app client / secrets for the library to load?
b
depends on how well you plan on hiding the secrets
the standard is probably guids/secrets, though that usually means implementing the crypto required from the login yourself
the alternative is generally hiding the secrets somewhere
custom record tends to be the choice, since there are more options to make it inconvenient to access
the other option besides file is script parameter
d
I would normally put secrets in a script parameter, I don't love that approach though. one of my developers did use the guid/secrets approach, I think he had a rough time getting it setup though, had to create a suitelet to store the secret.
would be nice if there were a secrets/vault option
b
d
I don't have this as an option: Setup > Company > Preferences > API Secrets So I'll ask our admin about it
b
i dont think its an option if you also have to support 1.0 scripts
d
yeah I saw only ss 2.0 is supported
b
you would still probably need a suitelet to generate the guids
generating the guids is the confusing part
👍 1
using them is hard and confusing
you basically use guids or secrets the same way
d
thanks @battk, I'll give secrets management a whirl
16 Views
Open in Slack
PreviousNext
Powered by