I am trying to include a widget in my webpage. The code for the widget is loaded dynamically with ajax (because it changes often and I need to update it from the server) and it looks like this ...
<a class="e-widget" href="https://gleam.io/0oIpw/contest-widget" rel="nofollow">This is a Widget!</a>
<script type="text/javascript" src="https://js.gleam.io/e.js" async="true"></script>
on load, I get the following errors in the console...
OPTIONS https://js.gleam.io/e.js 404 (Not Found)
XMLHttpRequest cannot load https://js.gleam.io/e.js. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'https://localhost:8443' is therefore not allowed access. The response had HTTP status code 404.
If I remove the ajax call that loads the data for the widget, and instead insert the widget directly, I do not get the same errors and the widget works fine.
I have read into this and figure that it is due to the Same-Origin-Policy (SOP), so I am now wondering the best way to circumvent the policy.
I have read the post Ways to circumvent the same-origin policy but unfortunately did not find it helpful in this case.
Since CORS is done on the server side (I think ? ) and JSONP is insecure, is the best option to create a proxy?
Thanks so much for the help. I have spent quite a few hours researching this and I am still confused.
Edited to add code for more info :
The information for the page is loaded via ajax when a command link is clicked as follows :
<h:commandLink action="#{redeemPerk.getDisplay(display.displayId)}" >
<h:graphicImage value="#{display.imgUrl}" styleClass="display-icon"/>
<f:ajax event="click" execute="#form" render="redeem-display-data-reveal" listener="#{redeemPerk.getDisplay(display.displayId)}" onevent="handleAjax"/>
</h:commandLink>
this renders the area that displays the widget, which looks like ...
<div class="reveal-modal-background hidden">
<h:form id="redeem-display-data-reveal">
<h:panelGroup rendered="#{display.type == 'WIDGET'}">
<a class="e-widget" href="https://gleam.io/0oIpw/contest-widget" rel="nofollow">This is a Widget!</a>
<script type="text/javascript" src="https://js.gleam.io/e.js" async="true"></script>
</h:form>
</div></h:panelGroup>
The second chunk of code is in a separate file from the first. To reiterate, if I remove the ajax call and load the data directly the widget works fine.
I am seeing two things in your output log that could be causing the issue.
First, it states that you received a 404 message from the request. Which means the JavaScript has probably not been uploaded properly.
Second, it says that the origin of the request came from localhost:8443. That leads me to believe that you are running the code locally instead of from the Internet.
In cases where you are trying to load a plugin from the internet, but your code is being tested locally you are still going to get an SOP error. To fix this problem you would need to upload all of the code that you do have to your web server. Once you have done that attempt to load the webpage from the Internet and not your local copy. That should fix that SOP error.
Related
I have a certification and a badge provided by Acclaim. I want to embed it in my personal website but it's not working. here's the code they provided:
<div data-iframe-width="150" data-iframe-height="270" data-share-badge-id="60615e70-6409-4752-9d77-3553a43d13d2" data-share-badge-host="https://www.youracclaim.com"></div>
<script type="text/javascript" async src="//cdn.youracclaim.com/assets/utilities/embed.js"></script>
but even when simply put onto an empty html:5 page, I get the error: Loading failed for the <script> with source “file:///assets/utilities/embed.js”.
What's the problem here? I'm not sure how Acclaim can provide a ready-to-paste script that's just simply not working, nothing shows up on the website. I'm guessing the problem is at the src... part, but don't know how to fix it.
If you're loading your page via file:, then protocol-relative URLs aren't going to work. The script tag has:
src="//cdn.youracclaim.com/assets/utilities/embed.js"
This should be changed to:
src="https://cdn.youracclaim.com/assets/utilities/embed.js"
You'll find though that when you're using an actual web server, this is a non-issue. The reason for the protocol-relative URLs is so that HTTP pages would use the HTTP version, and HTTPS would use the HTTPS version. This method is outdated anyway. HTTPS should be used everywhere, even if you're loading HTTPS JavaScript from an HTTP page.
I've been working on this internal web app that allows the users to click on a button to see an image. Pretty straight forward.
<img id="swatchimage" width="600" height="600" src="" />
The image needs to be linked from an external website. The piece of javascript that does that is:
$("#swatchimage").attr("src", fileURL);
One of the URLs look like this:
If you try to access the image above in a browser it works without a problem.
When accessing it from the internal app ( IP: 192.168.110.15 ) then the server returns 403 error.
The same files are used in the main website, so I don't think it's about the hot linking protection (which i tried to disable too, to no avail).
Is there some restriction that I'm not aware of when linking these kind of resources?
I think I found the problem:
The server (cdn.palmcentre.co.uk) is not sending an Access-Control-Allow-Origin header in the response, so you can't use JavaScript to fetch it.
However, this is not a 403. Here's a screenshot of the error I get:
Also, what you're trying to do is not to fetch the image, but modify the src attribute of an <image> element, which should be allowed.
This makes me think that the error you're getting is because jQuery is trying to fetch the image, and failing, but I'm not sure.
Try doing this instead:
document.getElementById("#swatchimage").src = fileURL;
It seems I have found the solution.
It was puzzling indeed, because i knew that CORS would not be at play here. It was just another image URL that was requested from an HTML tag. So it shouldn't have behaved in such way.
Notwithstanding the help received, for which I am grateful, it seems that the issue was in fact a hot linking protection that was in place.
But it was not from the server itself or from the script but rather from the CloudFlare cache itself.
I'm currently working on a project to track products from several websites. I use a python scraper to retrieve all the URLs related to the listed products, and later, regularly check if these URLs are still active.
To do so I use the Python requests module, run a get request and look at the response's status code. Usually I get 200, 301, 302 or 404 as expected, except in the following case:
http://www.sephora.fr/Parfum/Parfum-Femme/Totem-Orange-Eau-de-Toilette/P2232006
This product has been removed and while opening the link (sorry it's in French), I am briefly shown a placeholder page saying the product is not available anymore and then redirected to the home page (www.sephora.fr).
Oddly, Python still returns a 200 status code and so do various redirect tracers such as wheregoes.com or redirectdetective.com. The worst part is that the response URL still is the original, so I can't even trace it that way.
When analyzing with Chrome DevTools and preserving the logs, I see that at some point the page is reloaded. However I'm unable to find out where.
I'm guessing this is done client-side via Javascript, but I'm not quite sure how. Furthermore, I'd really need to be able to detect this change from within Python.
As a reference, here's a link to a working product:
http://www.sephora.fr/Parfum/Parfum-Femme/Kenzo-Jeu-d-Amour-Eau-de-Parfum/P1894014
Any leads?
Thank you !
Ludwig
The page has a meta tag, that redirects the page to the root URL:
<meta http-equiv="refresh" content="0; URL=/" />
Our static content server is serving images for various web portals (black box for me). On web portal all images are coming fine even though they are from different domain (assuming static server sets http headers accordingly). However if I try to access same image using browser console via ajax calls (using jquery or xmlhttp) it gives cross domain call failure error (i.e. request is successful but browser denied response). Below is a simple jsfiddle to show the problem
JSfiddle for image coming in dom but ajax call failing
/*Image tag works fine*/
<img src='https://casinogames.bwin.com/htmllobby/images/gameicon/melonmadness.jpg' />
/*ajax call fails*/
var a = $.ajax(' https://casinogames.bwin.com/htmllobby/images/gameicon/melonmadness.jpg');
I verified request/response headers and they are exactly same in both scenarios. I want to know if there is any specific difference between request from image tag and ajax? I tried both IE console and Chrome console and same results.
I want to know if there is any specific difference between request from image tag and ajax?
There won't be anything significantly different about the request, but either way you do it, the browser will not make the image data available to JavaScript when the request is a cross-origin one.
Displaying an image to the user from an img element is not a security risk.
Giving JavaScript written by a third party access to data from another server is a security risk.
You cannot make ajax calls from different domain in normal ways.
here is a discussion about it.
You can look it up as "cross domain ajax calls"
Edit
Show remote img via jquery like...
var a = $('img').prop ('src', 'http://placehold.it/10x10');
I want to use JavaScript to make a simple http get.
I used jQuery to perform my request. My code runs on IE8.0 but not in Chrome (ver 6.0).
My page has the following code: (to simplify, i made a simple request to a html page, but my needs is other)
<!DOCTYPE html PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html>
<script type"text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js"></script>
<SCRIPT TYPE="text/javascript" >
function sendGet(){
$.get(
"http://www.google.pt",
function(data) {
alert('page content: ' + data);
});
}
</SCRIPT>
<head>
<title> Http Get Demonstration </title>
</head>
<body>
<p/>
<input type="button" value="Http Get" onclick="sendGet();" />
</body>
</html>
As i said, when i load this page on IE and press the button, i get the alert with the html code. But in Chrome the alert appears with empty text (null?). In Chrome Console from "Developer tools" i get the message: "XMLHttpRequest cannot load http://www.google.pt/. Origin null is not allowed by Access-Control-Allow-Origin."
Anyone can explain me what's the meaning of this message? And what i should change to my page run in Chrome?
Thanks
Due to same origin policy you cannot send AJAX requests to different domains than the one hosting your page. So unless your page is hosted on http://google.pt you cannot send an AJAX request to this domain. One possible workaround is to setup a server side script on your domain which will act as bridge between google.pt and the client or use JSONP if the distant domain supports it.
Although i can't remember if i changed any IE option, the Darin Dimitrov seems explain my problem.
I found some tricks can be used (beyond the Dimitrov answer):
use a PHP script:
http://jquery-howto.blogspot.com/2009/04/cross-domain-ajax-querying-with-jquery.html
configure IE by editing regedit (not recomended):
http://msdn.microsoft.com/en-us/library/dd565656(VS.85).aspx
(I belive there's some other way to disable cross domain protection without editing regedit. But i couldn't find it)
Are you opening the html file directly from a file (e.g. does the address bar say file://usr/path/to/the/file)?
We've found chrome won't let you 'ajax' in files from other domains when running under file://. However, in Safari it works fine.
Best solution for us is to use something like MAMP to run a local Apache server.