Can someone please help me understand including an...
# sdf
c
Can someone please help me understand including an integration record in your SuiteApp? I've read the documentation and i've imported a test integration record into my SDF and deployed it to another account and it made the same integration record. How are user credentials working here for the integration? Does it just create the integration record and the end user has to go in and reset the credentials? Are the credentials tied to the account it was originally created in and you just hand out the client ID/secret to end users and they create their own access token? If you keep the credentials, I'm assuming that anyone that ever touches the original integration to reset credentials is going to mess up everyone using the integration record?
a
when you make requests via an integration you have to include the account id in the request header i think? so the user credentials to auth are only valid for the given account
to be clear... i have no idea I'm just speculating ๐Ÿ˜ง
c
I'm using RESTlets as my integration endpoint in NetSuite. Typically you make the integration and get the client ID/secret then create an access token for the token id/secret. If it's auto creating the integration record, does it retain the client ID/secret that you got from originally creating it?
I'm testing it out now because the documentation does not say at all... and they want you to include an integration record for BFN certification.
a
what is it you need the client secret for? ๐Ÿค”
when youre initially setting up the integration right? you have to give that to the system that's connecting?
c
You need the client/secret for the TBA set up
Like using postman to call the RESTlet you need it along w/ the token ID/secret
a
you need the SECRET for that not just the ID?
c
you need all 4 pieces
a
huh yeah then idk how that can work
and there's no way to GET the secret once its created
which means they'd have to create new... at which piont... why are you creating for them
c
Yeah i'm testing it now
Exactly
I don't understand the point really
a
hmm well if its in a suiteapp... and the 3rd party you're connecting to... is actuallly YOUR APP outside of NS
then you'd already have the client secret, so maybe you wouldn't need them to provide it
but that seems like its subverting OAuth at that point
and if its an input into generating the bearer token then yeah they're 100% gonna be SOL
c
I just tested where I had an integration record I named "TEST 1"... installed the suiteapp and it made "TEST 1"..Deleted the SuiteApp so it removed the record and modified in the orginal account to be named "TEST 2" and re-installed and it created an integration with "TEST 2"... so it must be that it just ALWAYS references that integration.
Which means it most likely references the client/secret it generated
I don't like it
Like if everyone uses this integration record, but someone goes into the "origin" account and resets the credentials on the integration record, then every client is screwed.
a
you can't reset credentials on an integration record
you can delete and create new
c
yeah you can
a
really? how?
you can't ever get the client secret again, you have to create new
c
You can edit in the origin account and hit "Reset Credentials"
a
๐Ÿคจ
c
You are right in that you can't reset it in the account you installed it into
but someone could still reset in the origin account and mess up all integrations.
a
sounds... not great
c
I need to confirm the behavior but the name definitely changes if you change it in the origin. The SDF is only a script ID reference so it must store it somewhere and pull it in.
a
maybe BFN want it in there so they can test it before approving? not for it to be part of the app that gets deployed?
who the hell knows why BNF want anything
c
It's definitely for deployment
a
wild
sounds insane
c
We can always include one and never use it
a
LOL
c
problem solved
a
๐Ÿ™Œ
e
1000000 1
c
This is what I was after.. thanks @ehcanadian