Notice: Trying to get property of non-object in /var/www/maps/api/place/DeletePlace.php on line 42
The error means that the application you're testing tries to read some property from something not being an object.
If the behaviour can be reproduced using a real browser it indicates a bug in your application
If it happens only with JMeter and isn't reproducible with the browser you need to cross check the request JMeter sends using View Results Tree listener and the request the browser sends using "Network" tab of your browser developer tools - the requests must be exactly the same (apart from dynamic parameters which need to be correlated)
The most common mistake when it comes to API testing using JMeter is that people forget to add HTTP Header Manager and configure it to send a valid Content-Type header
I think I tried all the possible combinations of headers and body for my POST request in JMeter but is giving me 400 Bad Request saying that the languagePairID parameter from the body is invalid even tho it is exactly same as in Postman.
My headers:
And the request:
Meanwhile in Postman in works perfectly fine:
I tried checking and unchecking the multipart/form-data and browser-compatible headers, but nothing seems to help. I read that using Wireshark might be useful in such cases but I think for this one is not possible as it is HTTPS. I will be very grateful for any advice.
Uncheck "Use mutipart/form-data"
Remove everything from the "Body Data" tab
Switch to "Parameters" tab and put your parameters there:
Going forward be informed that you can easily convert your Postman script into JMeter:
Start JMeter's HTTP(S) Test Script Recorder
Import JMeter's certificate to Postman
Configure Postman to use JMeter as the proxy
Run your request in Postman
JMeter will capture the request and generate relevant HTTP Request sampler and HTTP Header Manager
More information: How to Convert Your Postman API Tests to JMeter for Scaling
I'm trying test an app that uses ipfs-http-client module + infura.io as http provider. It doesn't work in testcafe's chrome (but it works everywhere else, like if I manually test my app in chrome). Here's the console error I'm getting:
POST http://192.168.1.33:62108/gkheFCZHj/https://ipfs.infura.io:5001/api/v0/add?stream-channels=true 400 (Bad Request)
I'm not sure what testcafe uses, maybe a proxy or something? But it looks like https://ipfs.infura.io:5001/api/v0/add?stream-channels=true is refusing the request. Any way to fix it? I'd like to keep using testcafe.
I've just started using Postman to test an API I am integrating to.
I have the following error that keeps showing up
Invalid CORS request
Note the following:
The API uses Bearer token authentication(OAuth2). I have this
working without a problem.
I do get the bearer token successfully, assign it to an Environment variable and then attempt to use it for the RESTful operations.
The problem is in the subsequent RESTful operation that uses the token.
When I use an old token (through a POST operation), it rightfully
tells me that it is expired and not authorized.
When I then generate a new one and try to run the restful call, it gives me that Invalid CORS request error.
Using cURL, I have no issues. But I am frustrated by Postman.
What I have found so far:
Using postman with Http POST requests - I don't get the part in bold
Just in case anybody else has this same problem, here is how to solve
it. Go to https://www.getpostman.com/docs/capture in your chrome
browser. Click on interceptor extension and then choose add to
chrome. Once it is added there is a new icon top right of both the
browser and postman that looks like a traffic light. In postman click
this and it turns green. Then add a header to every request going to
third light. Every header consists of the header name and a value.
Start typing over the header name and a list of allowed http headers
comes up. Choose "Origin". In the cell for value simply type the
full URL of your server. (Do not forget the 'http://' or 'https://').
What is the expected response to an invalid CORS request? - Best explanation I have seen so far on CORS errors.
The other material speaks about Access-Control-Allow-Method header, preflight requests
... and there is an illustrative Apache Tomcat flowchart of the CORS flow.
Here's the answer you found again:
Just in case anybody else has this same problem, here is how to solve it. Go to https://www.getpostman.com/docs/capture in your chrome browser. Click on interceptor extension and then choose add to chrome. Once it is added there is a new icon top right of both the browser and postman that looks like a traffic light. In postman click this and it turns green.
... With the bit in bold translated:
Then add a header to your request. The header Key should be "Origin" and the header Value should be the full URL of your server (Do not forget the http:// or https://).
Note that Chrome/Postman won't allow you to add a Header with a Key of Origin without the Interceptor plugin.
Also note that at least on my system the Interceptor icon no longer looks like a traffic light.
If your back-end service side code checks for origin of the request (just to avoid CORS attack) you may face this issues when testing your Rest API through postman.
How to Resolve this .?
You need to install a Chrome plugin called Postman Interceptor (https://chrome.google.com/webstore/detail/postman-interceptor/aicmkgpgakddgnaphhhpliifpcfhicfo?hl=en).
After successfully installing this plugin , in you Postman client you can see small icon called Postman Interceptor , you need to toggle it to turn it on.
Now you can add a Request header as below
RequestHeader Key "Origin"
RequestHeader Value "your application base URL"
Check this image
Now you should be able to over come CORS issues you are facing
Cheers !!
Just avoid using browser/chrome postman plugin. Use the desktop application instead!
Seems our server is seeing from a Postman manual HTTP POST that the orgin is invalid b/c its coming from Postman as "chrome-extension://fhbjgbiflinjbdggehcddcbncdddomop"
Not sure why or how to resolve on client/Postman side. Seems our server is correclty rejecting it as is though and issuing a 403.
Value of "Origin" header set in Postman request should be allowed in API backend. For example, using Spring Boot for API should have next:
#Configuration
public class WebConfig implements WebMvcConfigurer {
#Value("${cors.allowedOrigins}")
private String allowedOrigins;
#Override
public void addCorsMappings(CorsRegistry registry) {
registry.addMapping("/**")
.allowedOrigins(allowedOrigins)
.allowedMethods("*")
.allowedHeaders("*");
}
}
where allowedOrigins is set using application.properties property cors.allowedOrigins having comma separated list of allowed origins, eg:
cors.allowedOrings=http://localhost:8080,http://example.com
and set 'Origin' value in Postman to any url from cors.allowedOrigins
I was getting this error when testing my APIs on the postman. Even after meticulously configuring my cors. So I used Insomnia instead of Postman and it works fine. I guess sometimes postman is the problem as it needs some extra effort.
You can try new version of PostMan. To me it works after upgraded postman version from 5.5.5 to 7.36.5
when trying to read this kind of url
URL: http://v4.lscache2.c.youtube.com/videoplayback?ip=0.0.0.0&sparams=id,expire,ip,ipbits,itag,algorithm,burst,factor,oc:U0dWSlhTVF9FSkNNNl9QTVhJ&algorithm=throttle-factor&itag=34&ipbits=0&burst=40&sver=3&expire=1275886800&key=yt1&signature=89195E808CB3FBBC7BDE7298A1DC0613D7987F00.D3064112E8F479C523F8DF4FBFDF392CE48167C2&factor=1.25&id=34e01ad39b34b5c9&
I get this error
read/binary url
connecting to: v4.lscache2.c.youtube.com
** User Error: Error. Target url: http://v4.lscache2.c.youtube.com/videoplayback?ip=0.0.0.0&sparams=id,expire,ip,ipbits,
itag,algorithm...
** Near: read/binary url
In Rebol 3 you get:
** Access error: protocol error: "Server error: HTTP/1.1 403 Forbidden"
The message you're getting is Rebol 2's not-so-eloquent way of saying that. (You can also enter it in Firebug and see that using this raw URL does not work.)
I'd imagine that YouTube will only let you get the stream if the requesting HTTP header matches a certain pattern. Among potential things it might look for is a cookie specifically crafted for your session and designed to expire after a certain time.
As far as I understand it YouTube is not too keen on third party downloads of video data. They used to have a get_video API but appear to have disabled it. So you'll either have to fake up a cookie and make them think you're one of their players, or find a service which is friendlier to this sort of application.