I have a GET restlet to search for all employees in my Netsuite account.
I want to use fetch js function in my react application to get all the data from the restlet.
I have tried with postman to see and its works well there, but now I need to implement it on my react app
Where should I put the tokens and all the headers?
If this is a public app all your tokens should only be stored server side -- not in your react app on the client.
If this is a react app embedded in the UI then you don't need authentication because Netsuite allows internal restlet calls from the logged in user (as long as the restlet audiencing includes them).
The simplest thing to set up is to have your suitelet return JSON in response to a query with an action parameter
For local development I rely a lot on mock-server. Logged in to Netsuite I hit the suitelet with the action param and populate the mock-server files. Local dev just hits mock server.
A problem with Restlets (also a feature) is that they run with the permissions of the authenticated user. A suitelet can be run as administrator with audiencing to allow controlled access to resources that the users shouldn’t have unrestricted read or write access to.
Related
If I'm wrinting BDD style tests. What would be better practise:
When User A creates new record
Then DB contain correct record
or
When User A creates new record
Then User A can get his new record by some API request
And Admin-user can get this new record by another API request
So should I check internal state of DB or just use API and consider application + DB as a black box?
You should test your application as much as possible using the APIs, as it gives the actual behaviour of your application. In your case, it would be
When User A creates new record
Then User A can get his new record by
some API request
And Admin-user can get this new record by another API
request
Reason being:
By using the Admin API, you are making sure the record is in database and the Admin API behaves as expected
In the future, if your DB changes, which is internal to your application, but the API's behaviour doesn't change then your BDD would work without any issues. In other words, if the devs decide to change DB and not the API, the business service which uses the API is not impacted
If you test only DB, but the Admin API changes, your scenario would pass but the Business service, which uses the Admin API, would fail
The only scenario, you would check the record in DB directly without an API is, when there is no API to verify the record. You shouldn't develop an API purely for BDD. The Admin API should be used in a business service and if this is not the case, you can check the DB record directly (your 1st option).
PS: We have developed a product NoCodeBDD. As the name implies, you can automate BDD without any code using NoCodeBDD. I would love to get some feedback from the community. You can download a free version from www.nocodebdd.com/download
Generally the thing that creates should be the thing that validates. So
if a user (human interacting with a UI) creates
then a user interacting with the UI would validate by viewing the created thing.
if an api client creates
then the api client would validate by examine the response from the create call
additionally the api client could get the thing created using a link in the response
In both cases I would only consider validating via the DB as a temporary measure whilst you are working on the scenario
I've looked at various approaches to this but I'm yet to find one that is perfect for my set up.
I have a UI that calls the api to present data to a user - the UI doesn't require someone to login and i don't want to authenticate every user. What i'm trying to do is simply protect the api because with the url to the api, anyone will be able to access the data.
In my mind, i can create a password/ apikey of some sort and store that as an environment variable that is sent from the UI to the API whenever a request is made. On the API, that apikey/password is validated before allowing access to the api.
Does this sound wise? Would you suggest something else? Have i missed anything. All thoughts are welcome.
The solution sounds good to me. You can do something like this:
back-end: create a new REST endpoint (something like /api/get-token) in your Node.JS application which generates a token (or ID), saves it locally (maybe into a DBMS) and returns it as response. Then, in every endpoint you need to protect, you extract the token from the request and, before sending any "private" data, you check if the supplied token is valid, or not.
front-end: as soon as your application is loaded, you send a request to the newly created REST endpoint and store the given token locally (localStorage should be fine). Then, every time the UI needs to access "private" data, you simply supply the claim within the request.
The implementation should be pretty straight forward.
I need to edit request before sending it to endpoint.
Using Web Demo integration I'm able to send request to the endpoint.
But I can't edit the request in order to provide some extra data to request. Extra data is stored in localStorage so I need to do this in javascript.
I've already connected the agent to an endpoint that handle the request using fullfillment. The problem is that request misses data I can retrieve only from the browser. From fullfillment I can set headers and basic auth but statically and it is not enough.
So I need to add a step in request building/sending:
User write or tell something to embedded chat (Web Demo integration)
Dialogflow recognize intent, params, generate the request.
Additional step: Update the request in javascript
Forward cutomized request to the endpoint
Maybe it's not possible using Web Demo integration. In Documentation can't find a way to just send string or audio in order to receive the generated request.
First of all you will need a custom chat integration, not the default Dialogflow one. Something like Smooch or Kommunicate. The default web demo should only be used for testing your bot. There is NO way you would want to use that in a production environment.
I would save whatever is in the local storage in a database such as Firestore. Once that data is in the database you can use it to modify your request in your fulfillment.
So what I would do:
Have a way to identify a user and save its local storage to the database (as soon as someone clicks on your chat window or opens the chat window)
Once an intent is triggered you check which user is contacting you (through the way that you identified the user) and get all data from the database
Request the data in your fulfillment server
There is no other way in which this is possible. You can't change requests before your query hits Dialogflow.
look at this scenario : in my app I get the form in html of a website
that form displays customer info
now I can parse the form and get customer info
Or I can use a web service (SOAP or whatever) and get the same information
What is the difference?
On a general level, a website is displayed to a user in a browser making it consist of GET request through HTTP/HTTPS. A webservice is one that responds to more than just GET requests (eg. POST, PUT, DELETE). This means that a user can interact with data remotely. Like adding your post to stackoverflow.com, that meant you sent a POST request where stackoverflow can store the data contained in this post in some remote location, like a database.
Web service is a solution to integrate systems and comunications between different applications. Your app is a way to interact with this Service.
For our usecase/situation below; should we be using SuiteSignOn to make an outbound call or an inbound call?
Usecase:
We have a Netsuite webstore (SCA). People login and purchase medical tests from us. After customers have performed their medical test they can view their results in our external web application (PHP Laravel web app). We want to use 1 single sign on for both applications (NS webstore and Results web app). Ie, the user will use their SCA webstore account login details to login to both applications.
We expect customers to go to the Results web app and somehow login using their NetSuite user credentials. I assume NetSuite (SuiteSignOn) can embed a login form in a external web app?
So would the above usecase be considered a SuiteSignOn outbound call or SuiteSignOn inbound call?
Check into Google Auth. That is supposed to be released as soon as all of the 2017.1 upgrades are rolled out. That would allow you to use the same authentication credentials.