I am attempting a cross domain request with dojo. External url is of MIME type text/html the only content on the page is something like 1236. I tried
dojo.require("dojo.io.script");
dojo.ready(function() {
dojo.io.script.get({
url: "theexternalurl",
callbackParamName: "jsoncallback",
load: function(data) {
console.log(data);
}
});
});,
But that was no good. Any ideas on how this can be done with dojo?
I suspect you are bumping into the browser security here. Cross-domain requests will only work when using iframes or injecting scripts (as you have done) and when the content of that script is valid "text/javascript".
If you are trying to load "text/html" into the script, it won't work as it isn't a valid script. It is something most of us have tried to do at some point. I have spent hours trying to get around cross-domain restrictions and found the security blocking it to be solid.
See my answer here for more details.
If all you are trying to do is load the content onto the page then you could use an <iframe>. However, if you are trying to parse the loaded content in some way than I'm afraid it is a dead-end. Probably not the answer you were hoping for but it'll save you hours of frustration.
Related
I have created a private app from my store and try to hit https://API_KEY:PASS#STORE_NAME/admin/orders.json URL using ajax and curl. It is working if I use curl but not with ajax. Can anyone explain here what is the issue?
This might be a Cross origin problem. If you are using jQuery try to make an ajax call with dataType set to jsonp as shown here:
$.ajax("url", {
dataType: "jsonp",
success: function(data) {
console.log(data);
}
})
Like the other answer said, it's a cross origin problem (See CORS)
Best way to deal with it normally is Shopify App Proxy, but this isn't available to private apps, only custom apps. Best bet is to build a custom app and authenticate with OAuth2, assuming there's no other reason you've chosen to build a private app instead.
If the nature of your app permits the change to a custom app, the App Proxy will give you a {store-name}.myshopify.com/{resource} end point that will bypass the cross-origin issue, but forward the request to your remote server.
Also, when you're working with JS and something is not working, check the console, and share any errors. No one can really tell you why it's not working without seeing either the code, the error, or both, but this is a common enough stumbling block with AJAX since all this cross-origin security stuff got put into place that I'm 90% sure it's the answer.
I'm having a pretty weird problem with CORS on a webapp I'm trying to make
I'm using Servlets (Tomcat8.0) for the backend. It's a school project, so I can't use a framework
A GET request to http://localhost:8080/FileBox/dashboard
returns a JSON payload( plain json, not jsonp,which I could use, but its the same domain). I'm using ajax to make the XHR, but it's being blocked by chrome as CORS
Should this be happening, since I'm making the XHR from the same domain(host+port)
'localhost:8080/FileBox/dashboard.jsp'
to
'localhost:8080/FileBox/dashboard'
Please, and thank you for the help!
You aren't making a request to http://localhost:8080/FileBox/dashboard. The error message says you are making a cross-origin request using an unsupported scheme and that http is a supported scheme.
Presumably you have made the two mistakes of:
Getting the URL wrong
You should be using a relative URL:
/FileBox/dashboard
but are trying to use an absolute URL:
http://localhost:8080/FileBox/dashboard
but have typed it wrong and are actually requesting
localhost:8080/FileBox/dashboard
Not loading the page over HTTP to start with
Possibly by double clicking the file in your system file manager, you have bypassed your HTTP server and are loading something like file:///c:/users/you/yourproject/index.html
Combined with the previous mistake, you end up trying to request file:///c:/users/you/yourproject/localhost:8080/FileBox/dashboard, with Ajax and get a security violation.
Solution
Fix the URL to be a proper relative URL
Point your browser at http://localhost:8080 instead of double clicking files in your file manager
I know there are several screen scraping threads on here but none of the answers quite satisfied me.
I am trying to scrape the HTML from an external web page using javascript. I am using $.ajax and everything should work fine. Here is my code:
$.ajax({
url: "my.url/path",
dataType: 'text',
success: function(data) {
var myVar = $.get(url);
alert(myVar);
}
});
The only problem is that it is looking for the specified url within my web server. How do I use a proxy to get to an external web page?
Due to Cross Site Scripting restrictions, you're going to have to pass the desired URL to a page on your server that will query the URL in question from serverside, and then return the results to you. Take a look at the thread below and the incorporate that into your application and have it return the source when that page is hit by your AJAX function.
How to get the HTML source of a webpage in Ruby
Using a GET request is going to the be easiest way to transfer the URL of the page you want to fetch your server so you'll be able to call something like:
$.ajax("fetchPage.rb" + encodeURI(http://www.google.com))
Because you can't access the side in question directly from the server, you're going to have to pipe the serverside script through a proxy for the request to work, which really kind of depends on your setup. Taking a look at the Proxy class in Ruby:
http://ruby-doc.org/stdlib-1.9.3/libdoc/net/http/rdoc/Net/HTTP.html#method-c-Proxy
This might seem a bit backwards, but I want to use Perl (and Curl if possible) to get data from a site that is using Ajax to fill an HTML shell with information. How do I make these Javascript calls to get the data I need?
The website is here: http://www.jigsaw.com/showContactUpdateTab.xhtml?companyId=224230
Remember that AJAX calls are ordinary HTTP requests, so you always should be able to perform them.
Open Firebug or Web Inspector on the website you're talking about, you'll see some XHR calls:
XHR finished loading: "http://www.jigsaw.com/dwr/interface/UserActionAPI.js".
"http://www.jigsaw.com/dwr/call/plaincall/UserActionAPI.getMostPurchasedContacts.dwr".
"http://www.jigsaw.com/dwr/call/plaincall/UserActionAPI.getRecentlyGraveyardedContacts.dwr
"http://www.jigsaw.com/dwr/call/plaincall/UserActionAPI.getRecentlyAddedContacts.dwr".
"http://www.jigsaw.com/dwr/call/plaincall/UserActionAPI.getRecentlyTitleChangedContacts.dwr"
Yay! Now you know where to get that data. Their scripts use POST HTTP request to the URLs above, so if you open them in your browser, you'll see various engine errors.
When you sniff (via Web Inspector debugger, for example) their AJAX POST requests, you'll see the next body:
"callCount=1
page=/showContactUpdateTab.xhtml?companyId=224230
httpSessionId=F5E7EC4A45DFCE87B969A9F4FA06C361
scriptSessionId=D020EFF4333283B907402687182D03E034
c0-scriptName=UserActionAPI
c0-methodName=getRecentlyGraveyardedContacts
c0-id=0
c0-param0=number:224230
c0-param1=boolean:false
c0-param2=boolean:false
batchId=1
"
I'm pretty sure, they're generating a bunch of security session IDs to avoid data miners. You may need to dive into their JavaScript codes to learn more about those generators.
Some applications have code in place to check that the client is a real AJAX client. They simply the check for the presence of the header X-Requested-With: XMLHttpRequest. So it's easy to circumvent:
curl -H 'X-Requested-With: XMLHttpRequest' ...
use HTTP::Request::Common;
GET $url, 'X-Requested-With' => 'XMLHttpRequest', ...
Of course, you might have to deal with the usual stuff, like required cookies (for the session), nonce parameters, the occasional complexity. Firebug or the like for other browsers will help you reverse-engineer the required headers and parameters.
I have website that use XMLHttpRequest (jQuery, actually). I also have another site running on the same server, which serves a script file that makes XHR requests back to THAT site, ie.
http://mysite:50000/index.html includes
<script src="http://mysite:9000/otherscript.js"></script>
and http://mysite:9000/otherscript.js includes
$.ajax({
url: 'http://mysite:9000/ajax/stuff'
});
The problem is - this doesn't work. The AJAX requests from the loaded script simply fail with no error message. From what I've been able to find this is the old same origin policy. Given that I control both sites, is there anything I can do to make this work? The "document.domain" trick doesn't seem to do a thing for XMLHttpRequest.
Nope- can't do this with XHR. Same-domain policy is very restrictive there- same host, same port, same protocol. Sorry! You'll have to resort to other tricks (iframes, title manipulation, etc) to get it to work.
You can do this by adding Access-Control-Allow-Origin header.
If you are using PHP
header("Access-Control-Allow-Origin: http://example.com");
or in Node.js
response.writeHead(200, {'Access-Control-Allow-Origin':' http://example.com'});
This should do the trick for you. It always works for me.
I just solved a similar issue with a PHP service I'm currently playing around with (not sure how relevant a PHP solution is to this directly, but...) by making a single line proxy PHP page, SimpleProxy.php:
<?php
echo file_get_contents('http://localhost:4567');
?>
And in my XMLHttpRequest I use 'SimpleProxy.php' in place of 'http://localhost:4567', which effectively puts the request on the same domain as my .js code.