please help me. this not working. after call this method sms send properly but showing error this (failed)net::ERR_FAILED)
function sendSms(passWord, userName, smsRate, mType, MsgType) {
var getMessage = $('.composeSMS').val(),
number = '88'+$('[name="tags-input"]').val();
var convateMessage = setConvertedMessage(getMessage);
$.ajax({
type: 'get',
url: 'https://api.example.com:8443/sms/sms?',
headers: {
'Content-Type': 'application/json',
'Accept': 'application/json',
'Access-Control-Allow-Credentials': true,
'Access-Control-Allow-Headers': '*',
'Access-Control-Allow-Methods': 'GET, PUT, POST, DELETE, HEAD, OPTIONS, PATCH',
'Access-Control-Allow-Origin': '*',
'Access-Control-Expose-Headers': '*',
'Allow': 'GET, HEAD, POST, TRACE, OPTIONS',
},
data: { source: mType, username: userName, password: passWord, type: 2, destination: number, message: convateMessage,format: "json"
},
success: function( data ) {
conosle.log(data);
},
});
}
Error screenshort
CORS is not controlled by the consumer (the client browser) but by the provider (the cross origin server you are connecting to. CORS was introduced for security reasons, and there'd be no point if adding some headers completely disabled a servers ability to circumvent this security measure.
First thing to remove is the Access-Control-* headers from your request. These are response headers, and adding them to a request can result in otherwise functioning cross origin requests to fail - don't worry, this is a rookie mistake, you'll see this on stack overflow daily at least!
adding most headers will trigger an OPTIONS pre-flight check - which will fail if the server isn't expecting such a request
If, after you've made your your request is correct and has no extra (unexpected) headers in it, the request still fails, check the response headers - if there is no Access-Control-Allow-Origin in the response headers, then the server you are accessing does not allow browsers to make such a request
The solution then is to make the request from your own server, using server side code
As you have not mentioned anything about your server, let me try to help using some pseudo code
On the server you'd have something like
handle '/sms'
incoming parameters: source, username, password, type, destination, message, format
response = get(url { source, username, password, type, destination, message, format})
return response to client
Related
There is such a vue method:
methods: {
sendTrackerClientData () {
return axios.post("https://seo-gmbh.eu/couriertracker/json/couriertracker_api.php?action=tracking.data_save&key_id=00227220201402050613" , {
tracking_data: 'some data'
})
.then(response => {
console.log('post method is working!');
})
.catch(function (error) {
console.log(error);
});
},
}
Which is hung on a button click event
After trying to send data, we can see the warnings and error described above in the firebug.
Trying to add headers by type:
return axios.post("https://seo-gmbh.eu/couriertracker/json/couriertracker_api.php?action=tracking.data_save&key_id="+ this.$store.state.tracker.trackingKeyId , {
headers: {
'Access-Control-Allow-Origin': '*',
'Content-Type': 'application/json',
'X-Powered-By': 'bacon'
},
tracking_data: this.$store.state.tracker.trackingClientData
})
.then(response => {
console.log('post method is working!');
})
.catch(function (error) {
console.log(error);
});
It didn’t lead to anything.
Question:
How can I solve this problem?
OK, let's break this down:
axios.post("... lots of stuff ..."+ this.$store.state.tracker.trackingKeyId , {
headers: {
'Access-Control-Allow-Origin': '*',
'Content-Type': 'application/json',
'X-Powered-By': 'bacon'
},
tracking_data: this.$store.state.tracker.trackingClientData
})
The first argument you're passing to post is the URL. I'm going to assume that's the correct URL.
The second argument you're passing is this object:
{
headers: {
'Access-Control-Allow-Origin': '*',
'Content-Type': 'application/json',
'X-Powered-By': 'bacon'
},
tracking_data: this.$store.state.tracker.trackingClientData
}
This is wrong in multiple ways.
Firstly, you seem to be trying to add response headers as request headers. Neither Access-Control-Allow-Origin nor X-Powered-By should be there. They should be on the server.
But they aren't actually being set anyway because you've put the headers config in the wrong place. The arguments for post should be url, data, config. The headers need to go in the config, not the data.
axios will set the content-type header automatically. In the case of your request it'll set it to application/json. However, that will trigger a CORS preflight OPTIONS request as it isn't one of the 3 safe-listed content-types.
I don't know what content-type the API you're using expects but if you need to avoid the preflight request then you'll need to set it to one of application/x-www-form-urlencoded, multipart/form-data or text/plain. e.g.:
axios.post("... lots of stuff ..."+ this.$store.state.tracker.trackingKeyId , {
tracking_data: this.$store.state.tracker.trackingClientData
}, {
headers: {
'Content-Type': 'application/x-www-form-urlencoded'
}
})
However, the data is still being encoded as JSON here (so the content-type header and the request body don't actually match). I believe jQuery defaults to encoding the data as a URL encoded query string. The official axios documentation for doing that is here:
https://github.com/axios/axios#using-applicationx-www-form-urlencoded-format
However, all of this very much depends on exactly what format the server is expecting.
As you only have a single parameter it might be possible to do something like this:
axios.post(
"... lots of stuff ..."+ this.$store.state.tracker.trackingKeyId,
'tracking_data=' + encodeURIComponent(this.$store.state.tracker.trackingClientData),
{
headers: {
'Content-Type': 'application/x-www-form-urlencoded'
}
}
)
To debug this further you should carefully inspect the headers being sent each way in the Network tab of your browser's developer tools. Make sure they are exactly what you're expecting. There shouldn't be any mysteries here, you can see exactly what headers are being used.
Further, if you aren't clear on how CORS works and what can trigger a preflight OPTIONS request then you should do some background reading on that.
Finally, you need to find out exactly what format your server is expecting for the data. We can speculate all day about what the correct code might be but if we know what we're aiming for then there's no need to guess.
I would add that the jQuery example you posted has tracking_data spelt incorrectly as traking_data. That won't be related to the CORS error but it makes me wonder whether it really 'works'.
The issue means server restricts cross-origin requests. Those headers you've tried to add should be added on the server side. There is no way you can make it work without modifying your server code/settings.
According to the fetch specs it appears that as long as a Content-Type is specified that is one of "application/x-www-form-urlencoded", "multipart/form-data", or "text/plain" and other conditions are satisfied then a POST request should not result in a preflight request. In practice however I've had a difficult time specifying multiple headers for fetch in a way that doesn't cause the OPTIONS request for the preflight check.
ex 1.
fetch("https://differentsubodmain.example.com/api/resource", {
headers: {
"Content-Type": "text/plain, application/json",
Accept: "application/json"
},
method: "POST",
body: JSON.stringify({})
})
ex 2.
var myHeaders = new Headers();
myHeaders.append('Accept', 'application/json');
myHeaders.append('Content-Type', 'text/plain');
myHeaders.append('Content-Type', 'application/json');
fetch("https://differentsubodmain.example.com/api/resource", {
headers: myHeaders,
method: "POST",
body: JSON.stringify({})
})
ex 3.
fetch("https://differentsubodmain.example.com/api/resource", {
headers: [
["Content-Type", "application/json"],
["Content-Type", "text/plain"],
["Accept", "application/json"]
],
method: "POST",
body: JSON.stringify({})
})
Neither of these examples succeed in requesting without the preflight request but specifying either with only "Content-Type": "text/plain" appears to work just fine. The example here however shows both being specified in a request and suggests that it shouldn't cause a preflight. Is this just an issue with different browser implementations or am I missing something?
It looks like perhaps I hadn't read that reference carefully. Below is the important excerpt.
Warning. This intentionally does not use extract a MIME type as that algorithm is rather forgiving and servers are not expected to implement it.
If extract a MIME type were used the following request would not result in a CORS preflight and a naïve parser on the server might treat the request body as JSON
It looks like we are largely constrained to the mime types application/x-www-form-urlencoded, multipart/form-data, or text/plain to avoid preflight requests for CORS.
Reference:
https://fetch.spec.whatwg.org/#example-cors-safelisted-request-header-content-type
I'm having problems with cookie authentication between an expressJS server and a VueJS font-end.
When logging in through the site, I successfully get a HTTPOnly Cookie in the set-cookie header:
Screenshot (Ignore the Auth header, using it for testing only)
I also see the cookie in the devTools, and everything looks right too me, I'm not an expert on cookies though so it may not be correct
The problem is when I request the user's settings on another endpoint, the cookie is not sent to the server. The req.cookie object is empty when the this request is handled on the server side.
Here is my fetch code:
const loginOptions = {
method: 'POST',
mode: 'cors',
cache: 'no-cache',
headers: {
'Content-Type': 'application/json',
},
body: JSON.stringify({
email: email,
password: password,
}),
credentials: 'same-origin',
};
const settingsOptions = {
method: 'GET',
mode: 'cors',
cache: 'no-cache',
headers: {
'Content-Type': 'application/json',
},
credentials: 'same-origin',
};
const loginResponse = await fetch(baseUrl + '/login', loginOptions);
const userSettings = await fetch(baseUrl + '/settings', settingsOptions);
I've tried using credentials: "include", without success.
On the express server I'm using cors like this:
app.use(cors({
origin: '*',
credentials: true,
}));
Here is also an example of the second request, the 403 status is set by the server when no cookie is attached to the request.
I've tried setting the domain of the cookie to both localhost and 127.0.0.1 as suggested in another thread. I have left it on localhost for now.
Solved
I had read somewhere that you should add a specific domain value to the cookie when creating it. If I just removed that setting, it sets it automatically I'm guessing, and then it worked! So my guess is that I had set the domain value to the wrong value for what I was trying to do
Your response has access-control-allow-origin: http://localhost:8080 which implies you are making a cross-origin request.
You said:
credentials: 'same-origin',
… which tells your client-side code to only include credentials for same-origin requests.
I read somewhere that Chrome wasn't friendly with cookies and localhost env, maybe it could be that.
https://bugs.chromium.org/p/chromium/issues/detail?id=56211
Furthermore, I had some problems with cookies, express and vueJS some times ago.
Maybe it can help you: SetCookie header not stored
I had read somewhere that you should add a specific domain value to the cookie when creating it. If I just removed that setting, it sets it automatically I'm guessing, and then it worked! So my guess is that I had set the domain value to the wrong value for what I was trying to do
I'm trying to send a POST request from my website to my remote server but I encounter some CORS issues.
I searched in the internet but didn't find a solution to my specific problem.
This is my ajax request params:
var params = {
url: url,
method: 'POST',
data: JSON.stringify(data),
contentType: 'json',
headers: {
'Access-Control-Request-Origin': '*',
'Access-Control-Request-Methods': 'POST'
}
On the backend side in this is my code in python:
#app.route(SETTINGS_NAMESPACE + '/<string:product_name>', methods=['POST', 'OPTIONS'])
#graphs.time_method()
def get_settings(product_name):
settings_data = helper.param_validate_and_extract(request, None, required=True, type=dict, post_data=True)
settings_data = json.dumps(settings_data)
response = self._get_settings(product_name, settings_data)
return output_json(response, requests.codes.ok, headers = {
'Access-Control-Allow-Origin': '*',
'Access-Control-Allow-Methods': 'POST'
})
I get an error on my console:
XMLHttpRequest cannot load [http://path-to-my-server]. Request header field
Access-Control-Request-Methods is not allowed by
Access-Control-Allow-Headers in preflight response
I did notice that I can add also 'Access-Control-Request-Headers' but I wasn't sure if it necessary and it cause me more problems so I removed it.
Does anyone know how to solve this problem?
Your ajax request shouldn't send Access-Control headers, only the server sends those headers to allow the servers to describe the set of origins that are permitted to read that information using a web browser.
The same-origin policy generally doesn't apply outside browsers, so the server has to send CORS headers or JSONP data if the browser is going to be able to get the data.
The browser doesn't send those headers to the server, it doesn't have to, it's the server that decides whether or not the data is available to a specific origin.
Remove the header option from the params object, and it should work
I am trying to add a custom header, X-Query-Key, to a HTTP request using Fetch API or request but when I add this to the header of the request it appears to fail at setting the headers and the Request Method is set to OPTIONS for some reason.
When I remove the header it goes back to being GET as it should do.
Sample code looks like below:
const options = {
url: url,
headers: {
'Accept': 'application/json',
'X-Query-Key': '123456' //Adding this breaks the request
}
};
return request(options, (err, res, body) => {
console.log(body);
});
Try this:
const headers = new Headers({
"Accept": "application/json",
"X-Query-Key": "123456",
});
const options = {
url: url,
headers: headers
};
return request(options, (err, res, body) => {
console.log(body);
});
If that does not solve the issue, it may be related to CORS.
Custom headers on cross-origin requests must be supported by the
server from which the resource is requested. The server in this
example would need to be configured to accept the X-Custom-Header
header in order for the fetch to succeed. When a custom header is set,
the browser performs a preflight check. This means that the browser
first sends an OPTIONS request to the server to determine what HTTP
methods and headers are allowed by the server. If the server is
configured to accept the method and headers of the original request,
then it is sent. Otherwise, an error is thrown.
So you will have 2 requests if use custom headers, first one with method OPTIONS to check if server allows custom headers and after that if the server response is 200 OK and allows your originary request the second one will be send
Working with the Fetch API