I am trying to send a parameter after convert it to the base 64 the definition of the geddy.js route :
router.get(routing_prefix+'/gogetthecart/:data').to('Main.gogetthecart');
In the client side, javascript, I generate a base64 json data var jsonb64 = btoa(JSON.stringify(params)); after that I call the url that will somthing like this
http://www.mydomain.com//gogetthecart/GVudGl...aWNo=
I got Error: 404 Not Found.. But If I delete manually the = from the end of data that work
Solved by the community in the git repos issues https://github.com/geddy/geddy/issues/556 as Kieran said
I looked into adding support for base64 encoded vars to Barista
directly, but some characters in the b64 spec are reserved in the URI
spec. I don't feel comfortable making that the default behaviour.
However! You can simply override the behaviour to support this use
case:
router
.get( routing_prefix+'/gogetthecart/:data')
.to('Main.gogetthecart')
.where({
data: /[\w\-\/+]+={0,2}/ // base64-safe regex condition
})
and that should do the trick!
I added a test here:
https://github.com/kieran/barista/blob/master/tests/barista.test.js#L812
Related
I am using mockoon for API simulation. I created 2 routes there with method GET and its body contains(responds with) JSON object. I noticed that my express app is not able to parse one of the routes. But the route that has JSON object in body which contains ARRAY is getting parsed. I tested both routes with Express(by console.log) and in chrome browser(I have JSON formatter extension) and it is behaving the same meaning response that does not contain ARRAY is not getting parsed but the response with array is getting parsed(behaving normally). Let me show the screenshots:
Express(by console.log):
With array:
Without array:
Chrome(JSON Formatter extension):
With array(extension is able to parse):
Without array(extension is not able to parse):
I tried adding Header(Content-Type: application/json) to the route in mockoon. But still, I am not aware of what is going on here. Someone please explain
The express code:
const iabs_client = await axios.get(
"http://localhost:3001/iabs-client
);
Here is the route created in Mockoon(without array inside JSON):
P.S mockoon is a program that creates endpoints in localhost, useful for API simulation when developing front-end without having backend yet
The trailing comma after "something" is not valid JSON. Edit your Mockoon body to remove the comma and it should work.
I'm using simple-oauth2 in this example to query Microsoft Graph. All works well so far. But when I try to refresh the access token var newToken = await storedToken.refresh();, I get an error:
The content-type is not JSON compatible
This is thrown in wreck's index.js and it seems like there is no content-type set in the headers, while the mode is set to strict. The problem is, that I have no idea how to change this or why this is happening. It only happens on refresh().
I figured this is a configuration problem. The sample provides the config as follows
OAUTH_AUTHORITY=https://login.microsoftonline.com/common
OAUTH_ID_METADATA=/v2.0/.well-known/openid-configuration
OAUTH_AUTHORIZE_ENDPOINT=/oauth2/v2.0/authorize
OAUTH_TOKEN_ENDPOINT=/oauth2/v2.0/token
wreck uses Url.URL to combine OAUTH_AUTHORITY with OAUTH_TOKEN_ENDPOINT which results in https://login.microsoftonline.com/oauth2/v2.0/token and therefore loses common. This results in a 404 and therefore no JSON response anymore.
I changed the config slightly and removed the leading slashes from the relative paths and added a trailing slash to the base URL.
OAUTH_AUTHORITY=https://login.microsoftonline.com/common/
OAUTH_ID_METADATA=/v2.0/.well-known/openid-configuration
OAUTH_AUTHORIZE_ENDPOINT=oauth2/v2.0/authorize
OAUTH_TOKEN_ENDPOINT=oauth2/v2.0/token
So that OAUTH_TOKEN_ENDPOINT is relative. I have not figured why it worked for authorize though, but still works.
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.
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
Can routes in express not take a full URL as a parameter?
For example,
router.get("/new/:url", <some function>);
gives me the Cannot GET error when the :url is https://www.google.com
You can't get full URL like this format.This type of format is used to take parameters send by client
router.get("/new/:url", <some function>);
//you can get url as params
req.params.url//Use your URL
You should encode url parameter before sending. Your example encoded would be Http%3A%2F%2Fwww.google.com. On server side you can decode parameter to get value from before.
I think you are not much aware about ExpressJS routing because your url https://www.google.com have // which is used route separation.
In you case, we know that ExpressJS support regex route. I think following regex will work for you
app.get("/new/:protocol(http:|https:|ftp:)?/?/:url", <some function>);
In above case, you have bunded with limited protocol http, https and ftp. You may add more protocol by using | separator( or condition) and even you don't know what would be protocol then you like following
app.get("/new/:protocol?/?/:url", <some function>);
In above both route, ? means option that routes works file for
/new/www.google.com
/new/https://www.google.com
and in your function, you may append protocol in url like
function newUrl(req, res) {
if(req.params.protocol)
req.params.url = req.params.protocol + '//' + req.params.url;
console.log(req.params.url);
}