I'm trying to get the user info by using /users/:id as well as the user's group info /users/:id/groups using OKTA API and the problem is that the response is sent as a string format and I need to JSON.parse() it before using, which obviously is an extra job. Did anyone faced the same issue?
The solution was similar to the Noob Coder's comment, I've used the request middleware to make http requests, it gives you an request configuration option {json : true} which automatically
sets body but to JSON representation of value and adds Content-type: application/json header. Additionally, parses the response body as JSON.
Related
There is a system that sends POST requests from frontend to backend. These POST requests do not use the body to pass the data to the server; instead, it uses query strings in the URL params.
These requests do not send files or JSON, only several string params.
W3C does not describe that situation https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
Is it a bad practice to use query strings for POST requests, and if there any negative consequences of using that from security or performance or architecture reasons?
Are there any conventions that define the usage of body or query strings for different types of requests?
Reminder: In 2014, RFC2616 was replaced by multiple RFCs (7230-7237).
Is using a query string in POST request a bad practice?
Not if you know what you are doing.
Mechanically, it is all fine: are we allowed to use POST with a target-uri that includes a query-part? Yes. Are we allowed to use POST with an empty request body? Yes. Are we allowed to do both of those things at the same time? Yes.
The hard part: will this POST request invalidate the correct representations from the cache?
Cache-invalidation happens when the server returns a non-error response to an unsafe request (POST is an unsafe request method). The representations that are invalidated are those that match the target-uri of the unsafe request.
GET /foo?a=b HTTP/2.0
POST /foo?a=b HTTP/2.0
Here, if the POST is successful, the representations cached after the successful GET request will be invalidated in the cache.
GET /foo HTTP/2.0
POST /foo?a=b HTTP/2.0
Here, the effective request-uri is not the same, which means that general purpose components won't invalidate the cached representations of /foo.
There's nothing wrong with using query parameters in a URL in a POST request, with or without a request body. If it makes semantic sense for your request, it's fine. The POST method in itself has a semantic meaning distinct from GET, it doesn't require a request body to be useful, and the URL is yet distinct from that again. A classic example might be:
POST /foo/bar?token=83q2fn2093c8jm203
I.e., passing some sort of token through the URL.
There's no general security problem here, since anyone who could intercept this POST request to read the URL could also read its body data; you'll hardly find an attacker in a position that allows them to read the URL but not the body. However, URLs are typically logged in server access logs and browser histories, while request bodies aren't; that may or may not be worth considering, depending on what information you're transporting in those parameters and who has access to those logs.
Let's say I have a model called User with its basic REST CRUD (GET, POST, DELETE, UPDATE).
When I go to user/4 (where 4 is an ID of a User that doesn't exist), there are two cases:
If I'm doing it with a REST client like Postman, I'd get a 404 and nothing else.
If I'm on the browser, I'll get a 404 page (with text, images, etc), which is defined in the views folder.
How can I achieve this for findOne, find, and other URLs? I want to be able to have JSON-only responses, and HTML pages responses for different types of requests. But I don't want to override the functions, because the ORM is already doing a lot of work that I don't want to lose.
EDIT: My solution would be to leave the API with a prefix, such as /api/user/4 and the HTML response without the prefix user/4, but I'd like to see more elegant solutions.
EDIT 2: I just decided to go all JSON, and use a REST service only with an independent front end ;)
If you have control over the headers sent by the API client, I see two clean semantic solutions, based on the headers sent :
you could rely on the X-Requested-With: XMLHttpRequest header to recognize Ajax queries
rely on a Accept: text/json header to explicitly request json
You could also modify the url with file extensions to request a specific response, user/4.html => send html, user/4 => send json.
I'm trying to work out my mobile data usage & I noticed there are simple APIs to query on https://secure.example.com/myaccountmgr/fapi/usage/data/... but they carry an Authorization: 0a60bd4e0blahlblahhash in order to query them.
I copied the curl commands when logging in, but it does a fairly complex redirection dance that I not sure how to get curl to compute since it's Javascript.
How do people do this? After further debugging I noticed that it later does a AJAX request via Angular to https://secure.example.com/myaccountmgr/fapi/login/esso where it returns a utoken which is used in the subsequent AJAX requests as the Authorization value. So what I am asking, is how do I view just this response once I log in, so I can grab the token?
I am trying to pull information from Google Finances stock screener. There is no official api, so I am just making a get request to the same URL that they use on the site. I am using the URL at the bottom of the question, it can get a bit long. I can go to the url myself and it will give me a text file with the JSON information. In my javascript I am using $.getJSON on the url to get the screener results. But I get a Access-Control-Allow-Origin error, so I change output=json to output=jsonp&callback=?. But it only returns ();. From what I can tell this means that it is not set up on the other end to respond to a jsonp request and cannot return the proper information.
I have also tried output=json&callback=?, which produces the (); and output=json&callback=callbackFunction and output=json&callback=callbackFunction which both give me Access-Control-Allow-Origin.
Is there any way that I can make this work?
https://www.google.com/finance?output=json&start=0&num=20&noIL=1&q=[currency%20%3D%3D%20%22USD%22%20%26%20%28%28exchange%20%3D%3D%20%22OTCMKTS%22%29%20%7C%20%28exchange%20%3D%3D%20%22OTCBB%22%29%20%7C%20%28exchange%20%3D%3D%20%22NYSEMKT%22%29%20%7C%20%28exchange%20%3D%3D%20%22NYSEARCA%22%29%20%7C%20%28exchange%20%3D%3D%20%22NYSE%22%29%20%7C%20%28exchange%20%3D%3D%20%22NASDAQ%22%29%29%20%26%20%28market_cap%20%3E%3D%200%29%20%26%20%28market_cap%20%3C%3D%200.1%29]&restype=company&ei=GLyhVKmcDpOb8gbm7IGQAQ
If the service doesn't provide a JSONP endpoint or use CORS to grant you permission to access some other kind of endpoint, then there is no way to access the data using client side code.
Use server side code instead. You can use that to present the data to your client side code.
I'm trying to fetch some data from a server using nodejs. I would like to send a POST data. There are two things that I would like to know about.
How do I send the POST data?
Whatever request I make using GET or POST, I always get a 400-BadRequest error. Have been searching through to solve this the whole day. Was not able to solve.
I'm sending the POST data now like request.write(JSON.stringify({key:"value"})); .. for which I'm always getting a 400 to whatever site I try this. Even on apache running at 127.0.0.1 on a php file that accepts the POST data.
This question was answered in another SO thread: How to make an HTTP POST request in node.js?
Essentially:
use require('http');
set 'Content-Type': 'application/x-www-form-urlencoded' in the options
In the callback, use res.on('data', ...) to transfer the posted info.