10

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

Weston Boone
  • 345
  • 2
  • 3
  • 12
  • any messages in the javascript log? – John Dvorak Oct 17 '12 at 21:02
  • 2
    Check out [this question](http://stackoverflow.com/questions/1105934/ajax-using-https-on-an-http-page) Could be cross domain depending on whether your client page is on https also – Mark Meyer Oct 17 '12 at 21:05
  • I ran it with firebug and the chrome debug console and it does not register anything...good or bad. With http I can see responses from the script and everything as I should. – Weston Boone Oct 17 '12 at 21:06
  • @NuclearGhost Yeah I saw that post. I already have header('Access-Control-Allow-Origin: *'); in my script. It should not be a cross domain problem though since the traffic is not even getting to it to be potentially denied – Weston Boone Oct 17 '12 at 21:11
  • Please note that the traffic is denied at the client level - the browser is the one which refuses to make the call, not the server. To make things worse, most browsers silently fail without anything in the message log. Are you sure you're sending the Access-Control-Allow-Origin with all your responses, at the server-side ? – Marius Danila Oct 17 '12 at 21:17
  • @M.A.D. It does seem like the browser must be denying the traffic, but I am perplexed that it is allowed to another ip that I placed the script on. The main difference between the two addresses is the http vs https but either way it is a completely different domain and I would expect it to fail because of that regardless of the protocol. The script on my server does have Access-Control-Allow-Origin: * set so the problem must be client side.. it is sent from an https site to https. – Weston Boone Oct 18 '12 at 00:09

2 Answers2

2

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.

Community
  • 1
  • 1
Marius Danila
  • 10,311
  • 2
  • 34
  • 37
  • It is from an https to an https, but the javascript is being loaded as a widget through an application that I do not have control of (Zendesk) so it might be loaded from an http source I suppose... That does sound like the symptoms I am seeing. The port may be a problem too. – Weston Boone Oct 17 '12 at 21:19
  • Yes, the port is also part of the origin. – Marius Danila Oct 17 '12 at 21:20
  • You may need to enforce the header on the application which hosts the page that loads your js code. If you do not have access to it, I think JSONP might be your only choice left. – Marius Danila Oct 17 '12 at 21:25
0

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

davidkonrad
  • 83,997
  • 17
  • 205
  • 265