We Keep Coding

Is it possible to read a preflight requests in javascript

When we send non-simple request to another domain, the preflight request is being send first by the browser. Is it possible to somehow read the body or headers of preflight request responses in javascript?
For example:
fetch('example.com', { method: "DELETE" }).then(handler)
Will trigger a preflight request and if it succeeds, the "handler" function will be able to read a response for our main request. But is there any way to access the preflight request's response?

After looking through the fetch specification, my understanding of the request access is the preflight request will be returned if it had an error, otherwise, the main request will be returned (error or not) and the preflight will go inaccessible. However, I wasn't able to test this, and the specification wasn't the clearest for understanding the behavior of the function.
Edit:
I did some testing with https://test-cors.org, and found that I was wrong. Whenever the CORS request fails, all that you can get is the error object. If the request succeeds, all you get is the final response. The automated preflight request is completely hidden from JS, so as #Titus said in a comment, the only way to get the preflight response is to manually configure and send an OPTIONS request.

Basic authentication with header - Javascript XMLHttpRequest

I am trying to access Adyen test API that requires basic authentication credentials. https://docs.adyen.com/developers/ecommerce-integration
My credentials work when accessing the API page through browser.
But I get an 401 Unauthorized response when trying to access the API with XMLHttpRequest POST request.
Javascript Code
var url = "https://pal-test.adyen.com/pal/servlet/Payment/v25/authorise";
var username = "ws#Company.CompanyName";
var password = "J}5fJ6+?e6&lh/Zb0>r5y2W5t";
var base64Credentials = btoa(username+":"+password);
var xhttp = new XMLHttpRequest();
xhttp.open("POST", url, true);
xhttp.setRequestHeader("content-type", "application/json");
xhttp.setRequestHeader("Authorization", "Basic " + base64Credentials);
var requestParams = XXXXXXXX;
xhttp.send(requestParams);
Result

That screenshot shows “Request Method: OPTIONS”, which indicates the details displayed are for a CORS preflight OPTIONS request automatically made by your browser—not for your POST.
Your browser doesn’t (and can’t) send the Authorization header when it makes that OPTIONS request, and that causes the preflight to fail, so the browser never moves on to trying your POST.
As long as https://pal-test.adyen.com/pal/servlet/Payment/v25/authorise requires authentication for OPTIONS requests, there’s no way you can make a successful POST to it.
The reason is because what’s happening here is this:
Your code tells your browser it wants to send a request with the Authorization header.
Your browser says, OK, requests with the Authorization header require me to do a CORS preflight OPTIONS to make sure the server allows requests with that header.
Your browser sends the OPTIONS request to the server without the Authorization header—because the whole purpose of the OPTIONS check is to see if it’s OK to send that.
That server sees the OPTIONS request but instead of responding to it in a way that indicates it allows Authorization in requests, it rejects it with a 401 since it lacks that header.
Your browser expects a 200 or 204 response for the CORS preflight but instead gets that 401 response. So your browser stops right there and never tries the POST request from your code.

The PAL is a Payment Authorisation API. You never want to call it from a browser. You only want to expose your username and password to send in payments in your backend code.
In Client-side encryption, the encryption is done in the browser. You then send the encrypted data to your own server. On your server you then create a payment authorization request (of which the encrypted data is one of the elements, along side payment amount, etc).
If you would be able to manage to make this run from your browser, your end solution will allow your shoppers to change amounts, currency's, payment meta data etc from the JavaScript layer. This should never be the case.
The authorization is for that reason part of the "Server side" integration part of documentation: https://docs.adyen.com/developers/ecommerce-integration?ecommerce=ecommerce-integration#serverside
Depending on your server side landscape the CURL implementation in your favorite language differs, but most of the time are easy to find.
Kind regards,
Arnoud

Are HTTP headers handled automatically by the browser in AJAX responses?

Here's my situation: I make an ajax post to a server endpoint, and it sends me back some JSON data in response. This JSON response also includes the Set-cookie header.
Does the cookie get set automatically when it's in a response to an ajax request, or do I have to read it out of the headers and do it manually?
(As opposed to the headers being present on the response to a form submit, where I know the browser will be handling the response and its headers on its own, no JS necessarily involved.)

Yes, it gets set automatically. An AJAX request is just an HTTP request. You can send Cookie headers, and receive Set-Cookie Headers normally.

Angular:Why my angular app excute every $http request twice?

I'am sure it execute controllers once, but execute $http request twice.So every operation to my DB does twice!
The requests cross domain,and I set 'Access-Control-Allow-Origin:*'.
I get OPTIONS request before every normal request,but I guess the OPTIONS request have nothing to do with the TWICE problem.

This is preflight CORS requests. Notice that first request is OPTIONS and second one is POST.
This happens when you send request to other domain
Very good explanation: CORS - What is the motivation behind introducing preflight requests?

jquery json error, when i want to get json from steam market

I have a problem with ajax request to Steam.
I want to get price from steam market.
function jPrice(httpToJson) {
$.getJSON(httpToJson, function(data) {
return data.median_price;
});
}
When I call function
jPrice('http://steamcommunity.com/market/priceoverview/?country=US&currency=1&appid=730&market_hash_name=StatTrak%E2%84%A2%20P250%20%7C%20Steel%20Disruption%20%28Factory%20New%29');
I get an error:
XMLHttpRequest cannot load http://steamcommunity.com/market/priceoverview/?country=US&currency=1&appid=730&market_hash_name=StatTrak%E2%84%A2%20P250%20%7C%20Steel%20Disruption%20%28Factory%20New%29. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://lоcalhоst:63342' is therefore not allowed access.
I try:
Set php header Access-Control-Allow-Origin to *
JSONP
RESULT -> The same thing (error)!
Maybe someone knows a solution to this problem?

You won't be able to get the results in your browser via ajax request made directly against steamcommunity.com, neither by setting the header Access-Control-Allow-Origin to *, nor by sending a JSONP request.
For this to work, steamcommunity.com should either add CORS headers in the response (the error message you're seing means that they are not there), or format the output to be JSON-P. They didn't do either.
This is a browser restriction, do not allow the content from a different origin to be loaded via ajax. What you need to do is introduce a middle-ware, so have your back-end server to make a request against steamcommunity.com and return the same response, and make the ajax call against you're server. This will work, your back-end is sending the request, and as it is not a browser request, the response will land, than your ajax call will be able to get the response as well since it is issued against the same domain