So I'm working on Bigcommerce to build a website for a client. since Bigcommerce does not allow the upload of PHP files on their system I'm using AJAX in a script tag in an HTML file. The documentation for the API I'm using says to use my API key in the username field for HTTP Basic Authentication, and that all requests must be transmitted over HTTPS.
So firstly, here's my code
$.ajax({
type: 'POST',
url : "https://www.freightview.com/api/v1.0/rates",
data : ({ myRequest }),
dataType : "jsonp",
Accept: 'application/json',
beforeSend : function(xhr) {
xhr.setRequestHeader("Authorization", "Basic " + "MyKey:");
}
})
I've tried doing
Username : 'mykey'
and some other various ways to put the key in there but keep getting
401 Unauthroized
I've searched around for some ways to do this and noted a few possible issues:
Ajax GET request over HTTPS
It's mentioned on this page that AJAX cannot make cross-domain HTTPS requests. Does this mean I have to find another way to make the request? If so, how can I make such a request with the limitations I have?
Is it simply that I'm not properly defining my username for the Authentication? I'm hoping this is the only problem, but I've looked at a lot of questions on this site about Basic Auth in AJAX.
JQuery Ajax calls with HTTP Basic Authentication The user who asks this question seems to have a similar problem to mine, but the answers are quite varied, and I'm not sure if they'll work in my situation or even how to begin implementing them. Do I need CORS? Can I even get CORS to work on Bigcommerce?
So as you can see what I thought would be a relatively simple snippet of code turned out to be a lot more complex than I thought, and I could really use some of that StackOverflow magic!
Edit: grammar and spelling
In BigCommerce you have to encode your credentials with Base64.
Example:
// Define the string
var string = 'Hello World!';
// Encode the String
var encodedString = btoa(string);
console.log(encodedString); // Outputs: "SGVsbG8gV29ybGQh"
// Decode the String
var decodedString = atob(encodedString);
console.log(decodedString); // Outputs: "Hello World!"
Related
Following the guide here: https://shopify.dev/tutorials/display-data-on-an-online-store-with-an-application-proxy-app-extension
GET requests are working fine for me.
But when I try to do a POST request, my parameters are not coming through.
I'm building a simple wishlist app, where a user can click on a heart on a product and it adds it to a database.
So my code, when they click the heart, looks something like this:
$.ajax({
url: '/apps/wishlist/save',
type: 'POST',
data: {
shop: shop,
customerId: customerId,
productId: productId
},
dataType: 'json',
success: function (data) {
console.info(data);
}
});
When I inspect this post in Network tab in Chrome Dev Tools, the original POST is hitting a 301, then Shopify is creating a GET request to the original URL with different/missing parameters that look like this:
shop: example.myshopify.com
path_prefix: /apps/wishlist
timestamp: 1585769299
signature: examplesignature
If I change my original AJAX request to a GET, then my original parameters are passed as expected.
Are POST requests not allowed here?
Try to add / to the end of your url i.e. change it to /apps/wishlist/save/.
Just to give a clearification.
Vladimir answer works, why?
It seems that Shopify changed their authentication flow for some POSTs request.
You have to send requests without cookies or you can send requests with X-Shopify-Access-Token header and use your app's password for it. They should work both but there are some cases of use that doesn't permit you to send request without cookie or only uses basic auth (depending on wich method and software you use to send request). Shopify's devs are not crazy of course, this was implemented due to avoid some kind of hackers attack based on specific attacking methods, but maybe it should be better clearly specified in their documentation. Even if the solution explained above should be preferred, as said it could not work in some cases so the Vladimir 's solution is a valid alternative (you could also add a dot at the end of the URL so for example: www.example.com./etc/etc), this because this way "blocks" the cookie seending.
You can know more about that following Sopify's community discussion here
I'm trying to request a google sheet from the client in javascript, using jquery ajax.
The following code works in Chrome but fails in Firefox.
Question : how can I get it to work in Firefox?
If it's a server configuration issue then does this mean it's impossible to link to google drive documents from a firefox client?
Here is the code:
var url = 'http://docs.google.com/spreadsheets/export?id=1-on_GfmvaEcOk7HcWfKb8B6KFRv166RkLN2YmDEtDn4&exportFormat=csv';
$.ajax({
url : url,
type : 'GET',
dataType : 'text',
success : function(res, status){
console.log('status : ' + status);
console.log(res);
},
error : function(res, status, error){
console.log('status : ' + status);
console.log(res);
console.log(error);
}
});
In Chrome I get a 307 response then a 200 with the desired data.
In Firefox I get a only a 200 response but with the error message something like "Access-Control-Allow-Origin header missing, Same Origin Policy does not allow to fetch this resource".
The problem is that docs.google.com does not set CORS headers on redirects. And Chrome is not following the specification by not enforcing that and therefore has a security bug of sorts.
docs.google.com is in Chrome's HSTS preload list. The request to http://docs.google.com is transparently rewritten to https://docs.google.com, so no redirect happens.
I assume this will resolve itself if Firefox pulls an updated copy of the HSTS preload list. As Anne notes, simply changing the link to https directly will solve your use case.
I found a workaround by configuring Google Drive slightly differently, and using JSONP :
1) In Google Drive, Publish on the web the document & set sharing options to Public
2) Export your data in JSON format with a JSON type link, it will look like : "http://spreadsheets.google.com/feeds/list/YOUR_FILE_ID/od6/public/values?alt=json&callback=myCallback". You need to append &callback=myCallback to use JSONP. You can use jQuery to make your JSONP call.
3) To use the data, you need to define the callback function specified in the url , in this case "myCallback"
I've mentioned a similar procedure in a different answer but I think it can be useful to mention it here as well since it directly relates to the problem I was facing.
#EnricoFerreguti you should replace YOUR_FILE_ID with your file ID. Example : https://spreadsheets.google.com/feeds/list/1-on_GfmvaEcOk7HcWfKb8B6KFRv166RkLN2YmDEtDn4/od6/public/values?alt=json from the http://misterfresh.github.io/react-drive-cms/ website .
I am having a rather frustrating problem with the jquery post function that probably stems from not understanding how it works correctly.
I have a function that should post some form information to a php script that I wrote and that script then runs curl requests against an API to get around the cross-domain policy of javascript. It seems to work fine as long as it submits to "http" but when I send it to "https" the form never gets submitted.
I ran wireshark on my computer and it showed no traffic towards the destination ip until I made the url use http. I have basic auth on the server so I am passing the user and password through the url, but tested without that there and got the same results.
Here is the not working code:
$j.post("https://<api user>:<password>#<ip>:444/ProxyScript.php",
$j("#spoke_ticket").serialize(),
function(msg) {
log_status(msg);
fade_status();
$j(':input','#createtheticket')
.not(':button, :submit, :reset, :hidden')
.val('')
.removeAttr('checked')
.removeAttr('selected');
});
Here is the working function:
$j.post("http://<other ip>/ProxyScript.php",
$j("#spoke_ticket").serialize(),
function(msg) {
log_status(msg);
fade_status();
$j(':input','#createtheticket')
.not(':button, :submit, :reset, :hidden')
.val('')
.removeAttr('checked')
.removeAttr('selected');
});
Any ideas as to why the traffic is not being sent?
Let me know if I left out some key information or anything.
Thanks for the help
If you are doing the AJAX post from a http page to a https URL then the Cross-Domain policy kicks in because the protocol is also part of the origin specification, as it is described here. The browser will refuse to make the AJAX call, so that's why you're not seeing any traffic.
A solution is discussed here:
Ajax using https on an http page
So your best bet is the Access-Control-Allow-Origin header which should be supported on most modern browsers now.
So make your server add the following header to the responses:
Access-Control-Allow-Origin: https://www.mysite.com
If for some reason you cannot enforce this, then the only choice left would be JSONP.
Why not use a proxy to get over the cross-domain issue? It sounds more easy. An simple example is when i want to retrieve the danish administration national geo-data for counties,road names and so on (lucky for me, their data is in json or XML optional)
simplified proxy.php
<?
header('Content-type: application/json');
$url=$_GET['url'];
$html=file_get_contents($url);
echo $html;
?>
in ajax, get the lat/longs for a county borderline
var url= "proxy.php?url=https://geo.oiorest.dk/"+type+"/"+nr+"/graense.json";
$.ajax({
url: url,
dataType: 'json',
success: function (data) {
...
});
notice the https - the url could be, real example, https://geo.oiorest.dk/kommuner/0810/graense.json
I want to get xml data from google server using it's API. so, i can't make any changes to response. So, How do I make this call that work for me:
$.ajax({
type: 'POST',
url: 'https://www.google.com/accounts/ClientLogin',
contentType: 'application/x-www-form-urlencoded',
data: { accountType : "HOSTED", Email : ""+Adminemail+"", Passwd : ""+adminpass+"", service : "cp"}, // cp for contact service..
success: function (response) {
alert(response); });
I want make some GET, PUT, DELETE call as well so, I don't want to use any function like $.getJSON();I want to make it possible through $.ajax() only.
I think only way to do this is use of server side scripting language.
Most browsers won't allow cross site scripting. (An ajax call that is not in your own domain).
So if you want to call such an url (https://www.google.com/accounts/ClientLogin), do it server side.
Cross domain posting is blocked by the browser. You could write your own browser. Since this is probably not an option, you could post to your own server and from there post to the other server. I think you can post data to another server using cUrl if you're using PHP.
There's a nice example here.
The third party must provide a jsonp api.
I am making an ajax request using JQuery that looks like this:
var data = createXMLdata();
$.ajax({
url: 'http://localhost:8080/foo/bar',
type: "PUT",
data: data,
processData: false,
contentType: "application/text",
error: function(xhr, status, error) {
alert("Error: " + status);
},
success: function() {
alert("Success!");
}
});
When the code executes, I get the success alert, but the service is never executed on the server!
Here's some more data:
If I make the same request using a separate REST client, the service is executed correctly
If I shut down the server (nothing is running) so that hitting that URL gives me a 404, I still get a success message.
I have tried replacing the data with "foo". This works from the REST client, but gives the same result from the code.
Any ideas are greatly appreciated!
The documentation about .ajax()'s type attribute says:
The type of request to make ("POST" or "GET"), default is "GET". Note: Other HTTP request methods, such as PUT and DELETE, can also be used here, but they are not supported by all browsers.
So probably your browser does not support PUT and the data is sent via POST instead (and therefore not recognized by your service).
Use Firebug or similar to find out which method is used.
One idea to make it working:
Send the data using POST but add an additional field e.g. __http_method=PUT. On the server side, your service has to recognize this and perform the PUT functionality.
This might be not the nicest solution but it is also used by other frameworks I have encountered (e.g. symfony for PHP).
PUT isn't supported by all browsers
Nick Craver made a comment on my question:
Is the page you're running this in served from port 8080?
It turns out this led to me solving the problem. When both the app and the service were hosted on the same server (and port), the problem went away.
This post suggests that if I comment answers the question, and the commenter does not re-post as an answer, I am to post my own answer and accept it. Nick, if you return to post this as an answer, I will accept it over my own.