Is there a way to see the request body after I sended to server? I opened the developer toggle inside of ARC, but I access Network tab, I can't see my request. The only request showed is the collective, a request for google analytics.
It doesn't use Chrome's networking.
To see the message go to response details, request headers, source message.
I have been several days trying to understand how a chrome extension is working when a HTTP request is made.
I am using YARC (Yet Another Rest Client) Chrome extension. But I guess it works same for all. Even Postman.
First thing I see is when I make the request if I am using an http traffic viewer like fiddler, I can see the host is the same I am making the request (Like www.google.com) and if I make an Ajax request or a php request the host is the same i have the script (like localhost).
The other thing is that I am making a POST request to a site to make a login that set a cookie. If I make it with the chrome extension, the cookie is set on my browser and then I could navigate normally on that page and the cookie is set and I am logged in. If I make this post with Ajax or PHP i´ts impossible to set this cookie because my host is in a different domain (localhost).
I can see I could make a submit post for this, but then I got redirected after the submit and it´s impossible to avoid that. I would like to manage the response like the extension as it was an Ajax call.
The main thing I see here is that thy host is always on same domain and this could avoid all this problems. But HOW? Looking for YARC code I can see they make this request as a regular http angularjs, it means Ajax I am almost sure. Anywhay not even trying with angularjs http I can get this to work.
What I actually would need to do is how this Chrome extension could make this and how to set this cookie when I make this POST, I mean, the Host set the cookie on their own domain, cause I can get the cookie but not to set it and I know it is impossible from a different domain.
Thanks in advance for all your help.
I'm currently deploying a basic API to my live server and I'm running into (what I think is) a CORS problem but there is some behavior going on that I can't explain.
I'm communicating from an AngularJS front-end to a Laravel 5 (+ laravel-cors) back-end.
I started testing with a simple jQuery AJAX call (below) and when I make a request from my local Vagrant environment (http://dev.example.local/test.html) to http://api.example.com/v1/matches I get an error about Access-Control-Allow-Origin. The weird thing is that the request does come through because the information is stored in the database via the Laravel-based API correctly.
$.ajax({
method: 'POST',
url: 'http://api.example.com/v1/players',
data: {
"username": "username",
"first_name": "First",
"last_name": "Last",
"nickname": ""
}
}).always(function(r) {
console.log(r);
});
Error:
XMLHttpRequest cannot load http://api.example.com/v1/players. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://other.example.com' is therefore not allowed access.
The console.log(r) returns {readyState: 0, responseJSON: undefined, status: 0, statusText: "error"}
I developed the application locally using a Homestead VM (API) and a Vagrant environment (application) and it's working correctly within these environments...
Some observations:
Each of these requests shows up with Method: POST, Status: 200 OK, Type: xhr in my Chrome Developer Tools.
Tools like Postman and PhpStorm's RESTful service tester correctly execute the request and the data is added without errors.
Any ideas on how to further debug this problem are welcome... I've been trying to wrap my head around this for the entire day now and I just don't know what's causing it.
Your server must return an appropriate Access-Control-Allow-Origin header in the response. For example, if the request is being sent from http://stackoverflow.com, then your server must return this header: Access-Control-Allow-Origin: http://stackoverflow.com. You can determine, server-side, what the origin is by looking at the Origin header on the request. If your server does not return this header in the response, you will not have any access to the properties of the response browser-side (such as the status code, headers, or message body). The Same Origin Policy is at the center of this restriction.
The reason you are not seeing any similar issues when the request is sent by Postman or PhpStorm's RESTful service tester is due to the fact that these services do not send an Origin header with the request, as they are not subject to the Same Origin policy. By default, the browser will append this header to any cross-origin ajax requests, as browsers are subject to the Same Origin Policy. In my previous scenario, the request header would look like this: Origin: http://stackoverflow.com. Browsers that implement the CORS spec are required to add this request header so the server is able to determine if the origin of the request has been whitelisted for cross-origin ajax requests. If this is the case, the server will return the proper Access-Control-Allow-Origin header. If not, it can simply omit the header. Browsers that do not implement the CORS spec will simply refuse to send such an ajax request.
Regarding your bewilderment as to why the request is being sent in the first place, that comes down to a distinction between "simple" and "non-simple" CORS requests. For simple CORS requests, the request will always be sent to the server, but the client/JS will not be able to parse the response without proper acknowledgement from the server. Some CORS requests are not simple, so to speak. These are, for example, DELETE or PATCH requests, or POST/GET requests that contain non-standard headers (such as X-headers or a Content-Type of "application/json" as opposed to "multipart/form-data"). In other words, a request is not simple if it cannot be sent without JavaScript. For example, a <form> submit, or a GET request from a <script src="..."> will always send "simple" requests. For non-simple requests, the browser must "preflight" the request. This means that the browser sends an intermediate request, called a preflight, before the original request. This preflight request is an OPTIONS request. The server must than return headers in the response to this preflight that acknowledge any non-standard properties of the original request. If it does, then the browser will send the original request.
You can read more about preflighting and CORS in general on MDN.
I am using Angular v1.2.15 to GET a URL to retrieve JSON results.
I need to send a custom AUTHENTICATION Header with the request.
the url will send back Json.
So far I can only get both $resource and $http to even send the request
if I use JSONP type of request. However when I do this it does not send
my CUSTOM HEADER. Can I retrieve JSON content using a normal GET request?
The problem was the Ripple Emulator for Cordova apps was running the proxy on a different port. The the emulator was actually not allowing the http request.
I create a backbone app and a form to submit text value.
When I submit form, in "Net" tab in firebug I see:
How I can send form with Post method?
What need to do on server or something?
The options request you see is not send INSTEAD of your post request, it is called before the post request is triggered if you are in a cross-domain situation.
If you want to allow this on server side you could make your server respond with an additional HTTP header:
Access-Control-Allow-Origin: http://your.requesting.site.url