nestjs substitutes symbols in request body - node.js

I'm trying to send a request to my Nestjs application, with just plain string in the request body, for example:
test23+Se5+345
Then in my application, I have a middleware, where I need to do something with this string.
The problem is when I access request body in middleware const requestBody = Object.keys(req.body)[0];, this string looks like this:
test23 Se5 345
All of the + symbols are substituted by
I don't have additional convertings before this, and I know that middleware runs first in the request lifecycle. I think maybe there is some issue with body-parser, but I don't know yet how to fix this.

This is because symbol + is treated as space, so before send it, you need to encode your + characters to %2b. More here: How to encode the plus (+) symbol in a URL

Related

Handling UTF8 characters in express route parameters

I'm having an issue with a NodeJS REST api created using express.
I have two calls, a get and a post set up like this:
router.get('/:id', (request, response) => {
console.log(request.params.id);
});
router.post('/:id', (request, response) => {
console.log(request.params.id);
});
now, I want the ID to be able to contain special characters (UTF8).
The problem is, when I use postman to test the requests, it looks like they are encoded very differently:
GET http://localhost:3000/api/â outputs â
POST http://localhost:3000/api/â outputs â
Does anyone have any idea what I am missing here?
I must mention that the post call also contains a file upload so the content type will be multipart/form-data
You should encode your URL on the client and decode it on the server. See the following articles:
What is the proper way to URL encode Unicode characters?
Can urls have UTF-8 characters?
Which characters make a URL invalid?
For JavaScript, encodeURI may come in handy.
It looks like postman does UTF-8 encoding but NOT proper url encoding. Consequently, what you type in the request url box translates to something different than what would happen if you typed that url in a browser.
I'm requesting: GET localhost/ä but it encodes it on the wire as localhost/ä
(This is now an invalid URL because it contains non ascii characters)
But when I type localhost/ä in to google chrome, it correctly encodes the request as localhost/%C3%A4
So you could try manually url encoding your request to http://localhost:3000/api/%C3%A2
In my opinion this is a bug (perhaps a regression). I am using the latest version of PostMan v7.11.0 on MacOS.
Does anyone have any idea what I am missing here?
yeah, it doesn't output â, it outputs â, but whatever you're checking the result with, think you're reading something else (iso-8859-1 maybe?), not UTF-8, and renders it as â
Most likely, you're viewing the result in a web browser, and the web server is sending the wrong Content-Type header. try doing header("Content-type: text/plain;charset=utf-8"); or header("Content-type: text/html;charset=utf-8"); , then your browser should render your â correctly.

Bodyparser behavior after second question mark

I wrote a simple API which will return request.query as a response.
The behavior is little different than what I am expecting.
redirectto -- I am getting the only name as part of response redirectto param.
id -- I am getting an array in response.
Why is this behaviour?
Query parameters that contain reserved characters should be URL encoded or they will fail to parse correctly.
The properly encoded URL should look something like this:
http://localhost:8082/redirect?requesttype=click&id=79992&redirectto=http%3A%2F%2Flocalhost%3A8081%2Fredirect%3Fname%3Djohn%26id%3D123

HTTP trigger azure function won't bind route parameter with encoded slashes

I've created an Azure C# HTTP triggered function with a route url: subscriptions/{token}/t. It works fine for urls such as subscriptions/blah/t but it fails with a 404 for parameters that contain encoded slashes: subscriptions/blah%2fblah/t. Any way around this ?
Before we get into debates, {token} is a URL encoded Base64 string which will naturally contain slashes.
This issue seems to persist.
I found out that it can be resolved by double-escaping the string, that is, applying escaping recursively two times.
token = escape(escape(token));
In .NET you can use URI.EsacpeDataString()
In JS you can use encodeURIComponent()
Note, that single escaping does not work reliably with Azure functions
but it fails with a 404 for parameters that contain encoded slashes: subscriptions/blah%2fblah/t.
It is make sense because 'subscriptions/blah%2fblah/t' is equal to 'subscriptions/blah/blah/t'. I suggest you define your own encode rule for slashes. For example, you could convert all the slashes to '[[-]]'. Your token will be like this 'subscriptions/blah[[-]]blah/t'. After received the token, you could convert the special characters back.
token = token.Replace("[[-]]", "/");

Azure Logic App: how to make a x-www-form-encoded?

I'm trying to make a request with Content-Type x-www-form-urlencoded that works perfectly in postman but does not work in Azure Logic App I receive a Bad Request response for missing parameters, like I'd not send enything.
I'm using the Http action.
The body value is param1=value1&param2=value2, but I tried other formats.
HTTP Method: POST
URI : https://xxx/oauth2/token
In Headers section, add the below content-type:
Content-Type: application/x-www-form-urlencoded
And in the Body, add:
grant_type=xxx&client_id=xxx&resource=xxx&client_secret=xxx
Try out the below solution . Its working for me .
concat(
'grant_type=',encodeUriComponent('authorization_code'),
'&client_id=',encodeUriComponent('xxx'),
'&client_secret=',encodeUriComponent('xxx'),
'&redirect_uri=',encodeUriComponent('xxx'),
'&scope=',encodeUriComponent('xxx'),
'&code=',encodeUriComponent(triggerOutputs()['relativePathParameters']['code'])).
Here code is dynamic parameter coming from the previous flow's query parameter.
NOTE : **Do not forget to specify in header as Content-Type ->>>> application/x-www-form-urlencoded**
Answering this one, as I needed to make a call like this myself, today.
As Assaf mentions above, the request indeed has to be urlEncoded and a lot of times you want to compose the actual message payload.
Also, make sure to add the Content-Type header in the HTTP action with value application/x-www-form-urlencoded
therefore, you can use the following code to combine variables that get urlEncoded:
concat('token=', **encodeUriComponent**(body('ApplicationToken')?['value']),'&user=', **encodeUriComponent**(body('UserToken')?['value']),'&title=Stock+Order+Status+Changed&message=to+do')
When using the concat function (in composing), the curly braces are not needed.
First of all the body needs to be:
{ param1=value1&param2=value2 }
(i.e. surround with {})
That said, value1 and value2 should be url encoded. If they are a simple string (e..g a_b) then this would be find as is but if it is for exmaple https://a.b it should be converted to https%3A%2F%2Fa.b
The easiest way I found to do this is to use https://www.urlencoder.org/ to convert it. convert each param separately and put the converted value instead of the original one.
Here is the screenshot from the solution that works for me, I hope it will be helpful. This is example with Microsoft Graph API but will work with any other scenario:

Get params using ExpressJS

I'd like to get a specific param using ExpressJS with "#" instead of "?" in the url...
My URL :
http://localhost:3000/#access_token=LMkdfkdmsklmfdkslklmdskfmsda
I'd like to get "access_token" and "req.params.access_token" doesn't work...
Anthony
Short answer: you can't.
Longer answer: fragment identifiers (that's the part after the #) are supposed to be evaluated on the client and are not supposed to be sent to server. Your express app has no way of knowing them.
You could try to convert them to query parameters or path variables (i.e. by handling fragment identifier change in javascript) to make them visible server-side.

Resources