This seemed pretty straightforward:
capture a POST in Fiddler (Windows, because I find it easier to use than WireShark)
get data posted
make a similar POST using Net::Http in Ruby
And yet. Every time I run the post, it gets a 500. Could really use a suggestion here.
Original POST (Raw):
POST http://www.example.com/products/ajax HTTP/1.1
Host: www.example.com
Connection: keep-alive
Content-Length: 154
Origin: http://www.example.com
X-Requested-With: XMLHttpRequest
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.142 Safari/535.19
Content-Type: application/x-www-form-urlencoded
Accept: application/json, text/javascript, */*; q=0.01
Referer: http://www.example.com/products
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
q=getProducts&page=52&type=leaf_blowers
But when I get this in the Rails console:
>> res = http.post_form URI.parse(the_url), {'a' => 'getProducts', 'page'=> '52', 'type'=> 'leaf_blowers'}
=> #<Net::HTTPInternalServerError 500 Internal Server Error readbody=true>
The first one (Fiddler) results in HTML being returned. The second is just a 500 error. Is there anything obvious that I'm missing here? If you'd like to see the Wireshark capture, let me know how I can get it to look like the Fiddler raw capture -- I can't figure out how to get that detail out of Wireshark.
Maybe it's a typo when you posted the question, but the original post has
q=getProducts
and then you make the request with:
'a' => 'getProducts'
What happens if you make the request with 'q' => 'getProducts' ?
Related
I have this form where there is an implemented Google Captcha. I don't understand why I can submit multiple POST request using the same g-recaptcha-response and without it. Is it intended to work that way?
POST /dev-test/form.php HTTP/1.1
Host:.com
Content-Length: 606
Cache-Control: max-age=0
Sec-Ch-Ua: " Not;A Brand";v="99", "Google Chrome";v="91", "Chromium";v="91"
Sec-Ch-Ua-Mobile: ?0
Upgrade-Insecure-Requests: 1
Origin: https://sample.com
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.114 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: navigate
Sec-Fetch-User: ?1
Sec-Fetch-Dest: document
Referer: https://sample.com/dev-test/form.php
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
Connection: close
client_id=077&first_name=captcha-bypass-2nd-attempt&last_name=bypass-captcha-2nd-attempt&consent=true&g-recaptcha-response=
You can send as many request as you want to Google... The same way you can send unlimited mail parcel to an address, there's no mechanism to stop you from sending HTTP request to an address.
Once google receives your request, their servers will process your request and give it a score. It's your responsibility as a developer to go and get that score from google to check if a legitimate user is trying to access the site.
You will need to do that verification on the server side code of your application.
You can learn more on how google wants you to check the score at: https://developers.google.com/recaptcha/docs/verify
I have fetch api call from Vue js code which sends form-data to laravel backend
I am posting request. Please suggest how to parse this using laravel request?
POST /acapp/public/api/createmember HTTP/1.1
Accept: */*
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9,mr-IN;q=0.8,mr;q=0.7,ur-PK;q=0.6,ur;q=0.5,hi-IN;q=0.4,hi;q=0.3
Cache-Control: no-cache
Connection: keep-alive
Content-Length: 142
Content-Type: application/json
Host: localhost
Mimetype: multipart/form-data
Origin: chrome-extension://fhbjgbiflinjbdggehcddcbncdddomop
Postman-Token: cd1ca586-560b-fdf7-3fd6-afe2f457d676
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.77 Safari/537.36
------WebKitFormBoundaryoMWbAbNZyySY3vCB
Content-Disposition: form-data; name="dob"
45345345
------WebKitFormBoundaryoMWbAbNZyySY3vCB--
You don't need to parse the request. The HTTP-Request Stack of Laravel will do it automatically and call your action you defined for that url.
https://laravel.com/docs/5.7/requests
Here is a good example how to get informations from your request. So you don't have to think about that. In the documentation you can find a part how to write VUE components.
https://laravel.com/docs/5.7/frontend
i think that could help you.
I am using React With Redux and I wrote a middleware that comes in handy when I do Ajax calls in Epics. For example, to do a GET request, I have this getJSON function.
import {ajax, AjaxResponse} from "rxjs/ajax";
const getJSON = (url: string, headers?: Object): Observable<AjaxResponse> =>
ajax({
method: "GET",
url,
responseType: "json",
headers,
withCredentials: true
});
Everything seem to work fine except that Ajax does not set the headers that contains the access token.
When I step through the code, the headers object looks like this,
{
Authorization: "Bearer ey-SOME-ACCESS-TOKEN"
}
As expected... But when I look through the network calls, it does not contain the specified header with its value.
Parsed:
Accept: */*
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Access-Control-Request-Headers: authorization
Access-Control-Request-Method: GET
Connection: keep-alive
Host: localhost:1337
Origin: http://localhost:3000
Source:
OPTIONS /api/test HTTP/1.1
Host: localhost:1337
Connection: keep-alive
Access-Control-Request-Method: GET
Origin: http://localhost:3000
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36
Access-Control-Request-Headers: authorization
Accept: */*
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
NOTE: Please don't mark this as duplicate. I know there are similar questions on SO, but none of them seem to work for me.
After 3 days of pulling my hairs and banging my head on the walls, I finally figure out what is the problem, but still not sure why/how. Apparently due to CORS, there is always OPTION request is made before the actual POST or GET request. Which I already knew and kinda make sense. What does not make sense to me is why the heck it does not contain the headers. If anyone can explain this to me will be eligible for the bounty on this question.
I had to made changes in my back-end to handle OPTION requests, and it seems to work for now. I can't spend more time of this.
Not sure if it's late enough, but might be useful for future readers.
You should configure your server not to expect for authorization header in OPTIONS request.
The Bearer token is used for the POST/GET/DELETE/... confirmation of identity. The OPTIONS is just a preflight to see if the current HOST is allowed to get the data back.
It's important to say that browsers most of the time remove the custom headers from the OPTIONS request, moving them into the Access-Control-Request-Headers (it's happening in your case).
Please, take a look on the official documentation here:
https://www.w3.org/TR/cors/#cross-origin-request-with-preflight-0
I'm using a POST request in jmeter as below,
POST https://aumaz-ap-perf-ess-web-2.aumaz-ase-dev002.p.azurewebsites.net/signalr/connect
POST data:
clientProtocol=1.5&connectionData=%5B%7B%22name%22%3A%22bulkprocesshub%22%7D%5D&connectionToken=DWGWhf7zGj9TyO4cZn2kqH%2Bennba0V7qyAuAE2wIeu3vIoj%2FrLXemcaBz%2Fto3JjEs%2BaVviiFagxtax8E9PbE36cnBAlrByzw5qBwmIu9glop75vPY3XI0me52yTDiWC%2B9Zoalg%3D%3D&processId=b47fe282-8112-4a11-a18c-7629ac31b816&transport=longPolling
Request Headers:
X-Requested-With: XMLHttpRequest
Accept: text/plain, */*; q=0.01
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0
Referer: https://aumaz-ap-perf-ess-web-2.aumaz-ase-dev002.p.azurewebsites.net/ESS/DataType
Connection: keep-alive
Connection: keep-alive
Host: aumaz-ap-perf-ess-web-2.aumaz-ase-dev002.p.azurewebsites.net
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Content-Length: 315
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
If I use the same POST request in browser i can able to get the exact response. But in jmeter I'm getting the response as Bad request.
As of now, I'm using jmeter 3.01 and I have installed all the certificates needed. Can anyone please give solution for this
The most problem here seems to be that server doesn't respond with any details of what's wrong with the request. Correct?
Then do two things:
1) Install Fiddler, capture what you're sending through browser, and through JMeter, compare.
That may give you a clue what's the difference.
2) Reach server logs and see what's going on, there may be way more intrinsic information on why request was considered invalid.
I have finally got a solution. If I pass those parameters in parameters it doesn't work but i gave all the parameters with & in the path itself.
And used ${__urlencode{parameter}} to encode the parameters which are passing as encoded value and then I didn't face any Bad request issue.
Even now, I don't know how it worked. But finally got a solution by this way.
I've created a self hosted Web API (Web API 2.2 + Owin). The service is quite simple and only returns the list of GPIO pin values.
On my Pi itself, it works perfectly. I can call the service without problems. Only when I try to call it from my PC a HTTP 400 is returned:
Request:
GET http://192.168.178.105/RobotApi/GetGpioPinValues HTTP/1.1
Host: 192.168.178.105
Connection: keep-alive
Accept: application/json, text/plain, */*
Origin: http://localhost
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.95 Safari/537.36
Referer: http://localhost/piRobot.WebSite/index.html
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US,en;q=0.8,de-DE;q=0.6,de;q=0.4
Response:
HTTP/1.1 400 Bad Request
Content-Type: text/html; charset=utf-8
Server: Mono-HTTPAPI/1.0
Date: Fri, 02 Jan 2015 16:19:24 GMT
Content-Length: 35
Connection: close
<h1>Bad Request (Invalid host)</h1>
I hope someone out there can help me. Any suggestions?
Thanks a lot,
Dante
Ok. Got it:-)
It was no problem with raspberry or mono or Web Api itself. The self hosted service was initialized with the base URL http://localhost. The strange thing is, the service is only available via localhost, but not via the according IP address!!!
So what I've done now is, I substituted localhost with the IP address of my Pi and it works perfectly. Now the service is only accessible via the IP?!
I still have no clue why it makes a difference, but obviously it does.