So as usual, I tried to find this question on SO but still no luck.
I am aware that the answer is "Yes, you CAN modify the req object" but nothing is said about the req object parameters.
For example the following code will throw an error:
app.get('/search', function(req, res) {
req.param('q') = "something";
});
Error:
ReferenceError: Invalid left-hand side in assignment
I imagine this has something to do with the property not having a 'SET' method or something along those lines.
There are a few scenarios where this could come in handy.
A service that turns quick-links into full blown requests and proxies those out.
Simply modifying the parameters before sending it off to another function that you have no desire to modify.
Onto the question, Is there a way to modify the req object parameters?
Rather than:
req.param('q') = "something";
You'll need to use:
req.params.q = "something";
The first one is trying to set a value on the return value of the param function, not the parameter itself.
It's worth noting the req.param() method retrieves values from req.body, req.params and req.query all at once and in that order, but to set a value you need to specify which of those three it goes in:
req.body.q = "something";
// now: req.param('q') === "something"
req.query.r = "something else";
// now: req.param('r') === "something else"
That said unless you're permanently modifying something submitted from the client it might be better to put it somewhere else so it doesn't get mistaken for input from the client by any third party modules you're using.
Alternative approaches to set params in request (use any):
req.params.model = 'Model';
Or
req.params['model'] = 'Model';
Or
req.body.name = 'Name';
Or
req.body['name'] = 'Name';
Or
req.query.ids = ['id'];
Or
req.query['ids'] = ['id'];
Now get params as following:
var model = req.param('model');
var name = req.param('name');
var ids = req.param('ids');
One can also imagine that the left-hand side is not a variable or property, so it makes no sense to try to assign a value to it. If you want to change a query param you have to modify the property in the req.query object.
req.query.q = 'something';
The same goes for req.body and req.params.
Related
I want to write a cloud function that listens to whether a new document is created in the following subcollection of some document of users. However, the user document upon previous creation may not have a following subcollection.
In other words, I want a cloud that responds to db.collection(“users”).doc(“doc_id1”).collection(“following”).doc(“doc_id2”).set(new_document)
, and I have written the cloud function to be
exports.create_friend_request_onCreate = functions.firestore
.document("users/{user_id}/{following}/{following_id}")
.onCreate(f2);
And implementation of f2 is written in some other file
exports.f2 = async function(snapshot) {
//some code
}
However upon creation the document in the subcollection, I get the following error
Error: Value for argument "documentPath" is not a valid resource path. Path must be a non-empty string.
Can someone explain to me what is wrong here?
I had a same problem and this reason of the problem is doc path must be a string.
collection("questions").doc(21) is wrong.
collection("questions").doc("21") is work.
-you have to make sure the variables are strings
.You can use "users/{String(user_id)}/{following}/{String(following_id)}"
The correct path should have been 'users/{user_id}/following/{following_id}', apparently the double quotes cannot be used as paths.
Change this:
.document("users/{user_id}/{following}/{following_id}")
into this:
.document("users/{user_id}/following/{following_id}")
The collection shouldn't have a {wildcard}
This happened to me because in my Controller (of the API) I had something like this.
export const deleteUserGallery = async (req: Request, res: Response) => {
const { user_id } = req.params
You need to change your req.params to req.body if that's the case, to something like this:
export const deleteUserGallery = async (req: Request, res: Response) => {
const { user_id } = req.body
I am using Express with Body Parser. Given a below header key:
X-Master-Key
When I am using the below code snippet, it fails to output the value
req.headers['X-Master-Key'] // Fails
but when the above is changed to, it works
req.headers['x-master-key'] // Works
Further, when I tried to output req.headers, it turns out that Express outputs all the headers in a down-case format.
I started digging down further and tried using the below code, either of these snippets work
req.header('X-Master-Key'); // Works
// -- OR
req.header('x-master-key'); // Works
So what's the issue here? Why does Express changes all header keys to down-case? Moreover, how using req.header() is different from req.headers[]?
The problem arises because in the HTTP protocol, headers are case-insensitive. This means that content-type, Content-Type, and coNTEnt-tYPe all refer to the same header, and the Express framework needs to be able to handle any of them.
The different between req.headers (the object) and req.header (the function) is simply this:
If you want to get a property from a Javascript object, the property name is case-sensitive. So req.headers['content-type'] will work; req.headers['Content-Type'] will not. Why does the lower case version work? Because the Express framework, in an attempt to handle all the different possible cases (remember, HTTP will allow anything), converts everything to lower case.
But the developers of Express recognize that you (the developer) might be looking for Content-Type and you might not remember to convert to lower case, so they provided a function, req.header, which will take care of that for you.
So, in short:
This is recommended:
const myHeader = req.header('Content-Type');
Use whatever case you want - the function will convert it to lower case and look up the value in req.headers.
This is not recommended:
const myHeader = req.headers['Content-Type'];
If you don't use a lower-case header name, you won't get what you expect.
The problem comes down to case-sensitivity.
When you look at the documentation for req.get (which is aliased by req.header), it states:
Returns the specified HTTP request header field (case-insensitive match). The Referrer and Referer fields are interchangeable.
The w3 standard indicates that headers should be case-insensitive:
Each header field consists of a name followed by a colon (":") and the field value. Field names are case-insensitive.
So it would appear that node http module, which express uses, just treats them all as lower-case to "save you steps" according to this github issue
You can see that the express framework req object actually utilizes the node module http:
var accepts = require('accepts');
var deprecate = require('depd')('express');
var isIP = require('net').isIP;
var typeis = require('type-is');
var http = require('http');
var fresh = require('fresh');
var parseRange = require('range-parser');
var parse = require('parseurl');
Furthermore, in the code you can see that the req.header method converts whatever you give it to lower-case:
req.get =
req.header = function header(name) {
if (!name) {
throw new TypeError('name argument is required to req.get');
}
if (typeof name !== 'string') {
throw new TypeError('name must be a string to req.get');
}
var lc = name.toLowerCase();
switch (lc) {
case 'referer':
case 'referrer':
return this.headers.referrer
|| this.headers.referer;
default:
return this.headers[lc];
}
};
Finally, the http module parses headers using the matchKnownFields function which automatically lower-cases any and all headers that aren't "traditional headers", in which case it is case-insensitive.
Here is the responsible snippet, that implements the behavior you are seeing:
if (lowercased) {
return '\u0000' + field;
} else {
return matchKnownFields(field.toLowerCase(), true);
}
I'm still relatively new to NetSuite, and have taken over a project that a contractor did for us, so this may be a simple question. We have a Suitelet that is calling another Suitelet with nlapiRequestURL. The Suitelet that is being called, is supposed to return a single ID. Instead, we get a 'Invalid Page Parameter' response.
I looked at the configuration for the Suitelet that is called, and there is a parameter setup, but the 'Preference' field on that parameter is blank, which according to the documentation suggests that when that is the case, the parameter value should be defined in the Deployment, on the Parameter tab. Which it is, and appears to be the correct value.
So I assume the issue is with one of the parameters in the URL that is being used in nlapiRequestURL, and not the parameter defined on the script record in Netsuite. Here is an example of one of those URLs. I just changed the compid for obvious reasons:
https://forms.sandbox.netsuite.com/app/site/hosting/scriptlet.nl?script=147&deploy=1&compid=12345&h=e06792b0e7727d53f816&internalIds=17509
I verified that '147' is the correct script id. I also tried removing each of the parameters one by one from the URL, but that doesn't work. Depending on which one I remove, I either get 'An unexpected error occurred', or 'Missing a required parameter'. The only parameter that is being used inside the Suitelet that is called is 'internalids'. I can see that it's being obtained with 'request.getParameter("internalIds")'. (See code below)
As a sidenote, I'm not sure what the 'h' parameter is for in the URL, and can't find where that, or compid, or deploy is configured. I'm wondering if that 'h' value is incorrect, but am not sure what it's for. Why are 'compid', 'deploy' and 'h' being included in the URL? I can assume the compid is for identifying our company, but I'm not seeing how someone can determine how to build a URL for a request, since I don't know what mandatory parameters there are like that. I'm guessing I don't know where to look in Netsuite to find that configuration. Are there settings for base URLs somewhere?
Anyway, this is the script below that is being called. The other script is quite a bit longer, and has some company related info, so I'm not going to include it, but I don't think that matters anyway. The only thing that needs to be known is that we're using the URL above with nlapiRequestURL to call the script below, and calling 'getBody' on the result.
function suitelet(request, response){
nlapiLogExecution('DEBUG', 'suitelet', 'In the Preview_Link.suitelet function');
nlapiLogExecution('DEBUG', 'suitelet', 'The request is ' + JSON.stringify(request));
nlapiLogExecution('DEBUG', 'suitelet', 'The response is ' + JSON.stringify(response));
var context = nlapiGetContext();
var folderInternalId = context.getSetting('SCRIPT', 'custscript_buffer_folder_for_temp_pdf');
var strInternalIds = request.getParameter('internalIds');
if(!strInternalIds)
return;
var internalIds = strInternalIds.split(',');
if(!internalIds || internalIds.length == 0)
return;
var xml = "<?xml version=\"1.0\"?>\n<!DOCTYPE pdf PUBLIC \"-//big.faceless.org//report\" \"report-1.1.dtd\">\n";
xml += "<pdfset>";
for (var index = 0; index < internalIds.length; index++)
{
var internalId = internalIds[index];
xml += "<pdf src='"+ nlapiEscapeXML(nlapiLoadFile(internalId).getURL()) +"'/>";
}
xml += "</pdfset>";
var file = nlapiXMLToPDF(xml);
file.setName(internalIds[0] + '_' + internalIds.length + '_' + Math.random() +'.pdf');
file.setFolder(folderInternalId);
file.setIsOnline(true);
var internalIDUpdatedData = nlapiSubmitFile(file);
response.writeLine(internalIDUpdatedData);
}
So 'custscript_buffer_folder_for_temp_pdf' is the parameter defined on the Script record in Netsuite, and there is a value for it on that script's Deployment tab, on the Parameter tab, of '36', which is the value we want. That's our 'TEMP' folder in the File Cabinet. 'internalIds' is defined in the script that calls the one above, and it's either a single integer, or a comma separated list of them. (although it seems to always be a single value)
I should mention that this works in our production instance, and we just refreshed our Sandbox instance two days ago based on production. It didn't work in Sandbox prior to the refresh either. The only difference I can see, is that in production, the domain name is different in the URL, which of course it must be. All the code and settings appear to be identical besides that between the two environments.
Like I said, I'm new to Netsuite, so I haven't used nlapiRequestURL before. So this may be something incredibly stupid I'm overlooking. I've stepped through the code in the script that does the calling, but I can't seem to debug the Suitelet that is being called with nlapiRequestURL. I placed a nlapiLogExecution call as the first line in the script that is being called though, and it never even seems to hit that. I just get one of the errors I mentioned above before it actually steps into that script.
If anyone has any advice, I'd appreciate it. I've more or less exhausted my knowledge and resources. Thanks in advance, and let me know if you need further info.
Some things you may want to try:
var baseSuiteletURL = nlapiResolveURL('SUITELET', SUITELET_SCRIPT_ID, SUITELET_DEPLOYMENT_ID, true); //Getting URL from script id and deployment id
var reqUrl = baseSuiteletURL + "&internalids=17509"; //Adding your GET parameter here (all in lowercase)
var requestBody = {}; //Alternatively you could send your parameters within the POST body
requestBody.internalids = 17509;
var reqBody = JSON.stringify(requestBody);
var reqHeaders = {};
reqHeaders["User-Agent"] = "Mozilla/5.0"; //Sending user agent header to allow Suitelet to Suitelet calls
var myResponse = nlapiRequestURL(reqUrl, reqBody, reqHeaders);
Test sending your GET Query parameters (internalids) all in lowercase, I have experienced issues before in which the parameters case gets converted and it creates unnecessary troubles.
There is a generic structure of nodejs callback functions :
function(req,res){
//handle callback
}
I just want, callback should work correctly even if sometimes i write in mistake (res, req)
Given mixture of req or res, how do i find which one is actually request and which one is response.
req is an IncomingMessage object and res is a ServerResponse object.
So check for unique properties on each, for example if the particular object has a writeHead() function, then it's the response object.
You may also be able to use instanceof to check: res instanceof http.ServerResponse.
Functions in JavaScript are not programmatically prototyped by parameter names. The length property of a function only provides the number of parameters specified in the definition:
var fn = function (one,two,three) { return "x"; };
console.log(fn.length); // 3
Although there are ways to retrieve these names (see this question), usually procedures simply ignore how you name the parameters of your functions/closures, and instead assume that you are following the proposed API.
For this reason, it remains as the best practice to pay attention to the API and name parameters accordingly. In a Node.js HTTP request listener, the request comes always before the response (it is documented and many examples are available). As mentioned by other answers, you can dynamically check whether the request is an http.IncomingMessage or whether the response is an http.ServerResponse, but it seems to me that you can avoid introducing an overhead just with proper naming.
With that said, given the variables req and res, it is easy to make a check at the top of a function body, like the code below. However, do note that this would only be remedying what can be prevented by just following the API contracts, and as thus I cannot recommend it (unless you really want to make functions with a more flexible API).
function(res,req) {
if (req instanceof http.ServerResponse) {
// wrong order, swap.
var t = req;
req = res;
res = t;
}
// handle request
}
I have a nodejs express web server running on my box. I want to send a get request along with query parameters. Is there any way to find type of each query parameter like int,bool,string. The query parameters key value is not know to me. I interpret as a json object of key value pairs at server side.
You can't, as HTTP has no notion of types: everything is a string, including querystring parameters.
What you'll need to do is to use the req.query object and manually transform the strings into integers using parseInt():
req.query.someProperty = parseInt(req.query.someProperty);
You can also try
var someProperty = (+req.query.someProperty);
This worked for me!
As mentioned by Paul Mougel, http query and path variables are strings. However, these can be intercepted and modified before being handled. I do it like this:
var convertMembershipTypeToInt = function (req, res, next) {
req.params.membershipType = parseInt(req.params.membershipType);
next();
};
before:
router.get('/api/:membershipType(\\d+)/', api.membershipType);
after:
router.get('/api/:membershipType(\\d+)/', convertMembershipTypeToInt, api.membershipType);
In this case, req.params.membershipType is converted from a string to an integer. Note the regex to ensure that only integers are passed to the converter.
This have been answered a long ago but there's a workaround for parsing query params as strings to their proper types using 3rd party library express-query-parser
// without this parser
req.query = {a: 'null', b: 'true', c: {d: 'false', e: '3.14'}}
// with this parser
req.query = {a: null, b: true, c: {d: false, e: 3.14}}
let originalType = JSON.parse(req.query.someproperty);
In HTTP, querystring parameters are treated as string whether you have originally sent say [0,1] or 5 or "hello".
So we have to parse it using json parsing.
//You can use like that
let { page_number } : any = req.query;
page_number = +page_number;
Maybe this will be of any help to those who read this, but I like to use arrow functions to keep my code clean. Since all I do is change one variable it should only take one line of code:
module.exports = function(repo){
router.route('/:id',
(req, res, next) => { req.params.id = parseInt(req.params.id); next(); })
.get(repo.getById)
.delete(repo.deleteById)
.put(repo.updateById);
}