If I open these images directly on the browser, it won't work, but on the snipped it work. And I my localhost, I doesn't. Why is that? This is the error I am getting from my console log. How can I make sure that the images are always showing?
nikon-d1x-s.jpg:1 GET
http://www.vistaview360.com/cameras/images/nikon_images/nikon-d1x-s.jpg
403 (Forbidden) nikon-d1-s.jpg:1 GET
http://www.vistaview360.com/cameras/images/nikon_images/nikon-d1-s.jpg
403 (Forbidden) nikon-e3s-s.jpg:1 GET
http://www.vistaview360.com/cameras/images/nikon_images/nikon-e3s-s.jpg
403 (Forbidden) nikon-e2n-s.jpg:1 GET
http://www.vistaview360.com/cameras/images/nikon_images/nikon-e2n-s.jpg
403 (Forbidden) nikon-e2-s.jpg:1 GET
http://www.vistaview360.com/cameras/images/nikon_images/nikon-e2-s.jpg
403 (Forbidden) dance.html:145 scrool
<img src="http://www.vistaview360.com/cameras/images/nikon_images/nikon-d1x-s.jpg" "/>
The site is preventing you from accessing the images across site origins. The host is most likely only allowing origins from their domain or blocking based on a header like user-agent. They're doing this so you can't host the images on another site because they have to pay for the bandwidth every time it's accessed. So the answer is, you cannot cross host the images like this.
Instead, you'll need to download the images and host them yourself or contact the host and ask them to whitelist your domain. This will not help for localhost, however.
Most likely, the server has some checks in place to prevent hot linking.
Those checks vary in type. Some servers check the referrer string, others some cookies, etc.
I wouldn't try to include those images in your website because the intentions are clear: the remote server doesn't want you to include them and you don't know which measures they'll implement in the future to prevent you from doing that, so it could break at any time.
Instead, download those images and serve your own copies (provided you are not infringing any copyright, that is...)
If you still want to hot link them, compare the headers in the requests your browser is making with the ones sent when you can access them to try and find the culprit.
Related
I am using the following
Header set Content-Security-Policy: "frame-ancestors http://bmx-tv.net https://bmx-tv.net http://site.bmx-tv.top https://site.bmx-tv.top http://ps1.bmx-tv.top https://ps1.bmx-tv.top;"
on a blank .HTaccess page to try to prevent all sites besides those listed from being allowed to iframe my website but when i save the .htaccess it breaks my website with
Internal Server Error The server encountered an internal error or misconfiguration and was unable to complete your request. Please contact the server administrator at webmaster#localhost to inform them of the time this error occurred, and the actions you performed just before this error. More information about this error may be available in the server error log
Any idea what im doing wrong? or how to only allow certain urls to iframe me? i need this fixed there stealing my content but i cant lock it down to only parent because i have other urls i want to iframe my own content on.
Where do you get the : from? The apache docs show no : and has the following example:
Header set MyHeader "%D %t"
Therefore it should be:
Header set Content-Security-Policy "frame-ancestors http://bmx-tv.net https://bmx-tv.net http://site.bmx-tv.top https://site.bmx-tv.top http://ps1.bmx-tv.top https://ps1.bmx-tv.top;"
There is even a website which shows you how to enable and configure the Content-Security-Policy Header for a lot of systems. Also Apache.
Looked over some relevant posts:
Why am I getting a 404 error with ng-src even though image is appearing?
AngularJS ng-src path to image
Understanding AngularJS ng-src
Conditionally change img src based on model data
but none have the exact same symptoms.
This line of code,
<img ng-src="{{movie.Poster}}" alt="">
where movie is JSON and movie.Poster is a string of a url, seems to be the root of this error:
GET http://ia.media-imdb.com/images/M/MV5BMTk3OTIzODUyOV5BMl5BanBnXkFtZTYwNjgxNjA5._V1_SX300.jpg 403 (Forbidden)
Because the image url is good and complete in the error, the url string property movie.Poster seems to have been passed to ng-src ok/in time. However, many of the seemingly relevant posts emphasize that asynchronicity of JS may be responsible (and in this case movie.Poster does depend on a response from an API).
But if the url is in the error, why does ng-src have a problem requesting the image and displaying anything at all? An above post closest to my issue was able to load the image AND give the console error...
Perhaps the oddest thing is if I navigate to the image url (by copying and pasting that url) into another tab on the browser, then return to my app and click back then forward, the image loads without error!
I tried ng-if="movie.Poster"
and...
$scope anotherVar = movie.Poster in the controller and then ng-src="{{anotherVar}}"
Your Error is 403.
Which indicate that the server can be reached and understood the request, but refuses to take any further action. Status code 403 responses are the result of the web server being configured to deny access, for some reason, to the requested resource by the client .
Your image URL may be correct but you don’t have permission to access that.
http://ia.media-imdb.com/images/M/MV5BMTk3OTIzODUyOV5BMl5BanBnXkFtZTYwNjgxNjA5._V1_SX300.jpg
Doesn't seem to be an angular problem, as much as one with the API,
403 when trying to download a remote image
403 error for loading image from http and not https
Confused about how to handle CORS OPTIONS preflight requests
So, it seems that the headers need to be modified according to the first linked post in this answer...
But I checked that User-Agent is defined in the request to the image and it is...Even tried hard-coding one of the urls in the ng-src and THAT gave same 403...
AND I have colleagues who built the same app with same api without issue!
I am currently attempting to wrap a web application (ConnectWise) for inclusion within my company's central intranet site. It's a fairly simple process for the most part; create a containing page, with an iframe, point the iframe at the ConnectWise url. This part works for almost all of the functionality.
The problem comes during certain select features of the app (in this case, part of the process of creating a timesheet entry), which simply fail to work. Chrome gives the following console output.
Uncaught SecurityError: Failed to read the 'frame' property from 'Window': Blocked a frame with origin "https://app.example.com" from accessing a frame with origin "https://host.example.com". Protocols, domains, and ports must match.
I am aware this is caused by the security options for cross-site and same-origin policies. Given the following points, is there a way to overcome this?
I have full control over https://host.example.com
I can change html, javascript, and file contents
I can change IIS settings and headers
I have partial control over https://app.example.com
I can not change html, javascript, and file contents
I can change IIS settings and headers.
I have tried setting the Access-Control-Allow-Origin on each server, which so far is the only method I've come across that does not involve being able to change the file contents for the app server. This does not appear to work when given the settings (and combinations of settings) of
* or https://app.example.com while on https://host.example.com
* or https://host.example.com while on https://app.example.com
Edit:
The solution to this "duplicate" question is not applicable here. I do not have access to change file contents (including javascript) of the iframed page (app.example.com). Additionally, the script requiring the permission to run is the page within the iframe, not the page hosting the iframe.
CORS headers such as Access-Control-Allow-Origin only affect AJAX requests, not DOM access.
However, If they are both on the same domain but different subdomains then you can include the following on each page:
document.domain = 'example.com';
From MDN:
One document is allowed to access another if they have both set
document.domain to the same value, indicating their intent to
cooperate
If app.example.com has any script includes to host.example.com then you could put the above code in those scripts to set the domain.
e.g.
<script src="https://host.example.com/setup.js"></script>
No, it is not possible.
Access-Control-Allow-Origin primarily affects getting raw data from HTTP requests, not live DOMs.
postMessage can let frames on different origins communicate, but it requires JS to be included on both pages.
I'm working on a Chrome extension part of which is a function which manipulates images on a page using canvas and its context.getImageData function. That's when I ran into CORS issues. It's my understanding that a server serving an image has to server said image with appropriate CORS headers in order for cross-domain requests to be successful. I started reading up on this (to me) new and unfamiliar technology (tutorial). A substantial number of servers doesn't employ CORS and it's very important for the function of my extension that every image is processed. I've spent a whole day trying to circumvent this issue using client-side scripting but came to the conclusion that the only way is to send the image url to a server and then serve it back with the needed CORS headers (Access-Control-Allow-Origin: *). Now before I get into explaining my implementation I'd like to quote a paragraph from the tutorial page I linked previously.
Cross-Domain from Chrome Extensions
Chrome extensions support cross-domain requests in a two different ways:
Include domain in manifest.json - Chrome extensions can make cross-domain requests to any domain if the domain is included in the "permissions" section of the manifest.json file:
"permissions": [ "http://*.html5rocks.com"]
The server doesn't need to include any additional CORS headers or do any more work in order for the request to succeed.
This should mean that "permissions": "<all_urls>" should circumvent same origin policy restrictions. However, this does not work.
My solution
An XMLHttpRequest passes the image url and callback function to the server on localhost (for testing purposes) which first sets the appropriate header:
header('Access-Control-Allow-Origin: *');,
and then prints a JSON encoded array containing image width, height, and using file_get_contents, imagecreatefromstring, and base64_encode, the equivalent of context.getImageData and a call to the callback function.
The callback function sets the src property of an Image Object (that has crossOrigin set to Anonymous) which is used for drawing the images onto the canvas and sets it's width and height properties.
Result
The expected result was for every image to be loaded and processed without raising a Cross-origin image load denied by Cross-Origin Resource Sharing policy error, however now every image seems to be served without the needed CORS headers crippling my extension. I checked the headers the page on localhost which processes this request sends and it seems to be okay. (screenshot)
Conclusion
My implementation of this solution seems like it should work and I really have no idea why it doesn't. The server is sending the Access-Control-Allow-Origin header, the image data is good and the callback function is called. This is the only issue left to resolve before release. This is a really intriguing issue. I realise the header I'm sending isn't the only one I might want to send but it's sufficient for testing purposes.
I hope this question was clear, and detailed enough for someone to help me resolve this issue. Please do not hesitate to ask for more information and/or code snippets as I didn't really include any code in an attempt to keep this concise.
If your image src is a data uri (base64 encoded image data), then there is no headers to set access control.
Just set the image source to the url you're calling in ajax and send back the image not encoded(echo file_get_contents).
For posting AJAX forms in a form with many parameters, I am using a solution of creating an iframe, posting the form to it by POST, and then accessing the iframe's content.
specifically, I am accessing the content like this:
$("some_iframe_id").get(0).contentWindow.document
I tested it and it worked.
On some of the pages, I started getting an "Access is denied" error. As far as I know, this shouldn't happen if the iframe is served from the same domain.
I'm pretty sure it was working before. Anybody have a clue?
If I'm not being clear enough: I'm posting to the same domain. So this is not a cross-domain request. I am testing on IE only.
P.S. I can't use simple ajax POST queries (don't ask...)
Solved it by myself!
The problem was, that even though the correct response was being sent (verified with Fiddler), it was being sent with an HTTP 500 error code (instead of 200).
So it turns out, that if a response is sent with an error code, IE replaces the content of the iframe with an error message loaded from the disk (res://ieframe.dll/http_500.htm), and that causes the cross-domain access denied error.
Beware of security limitations associated to iFrames, like Cross domain restriction (aka CORS). Below are 3 common errors related to CORS :
Load an iFrame with a different domain. (Ex: opening "www.foo.com" while top frame is "www.ooof.com")
Load an iFrame with a different port: iFrame's URL port differs from the one of the top frame.
Different protocols : loading iFrame resource via HTTPS while parent Frame uses HTTP.
My issue was the X-Frame-Options HTTP header. My Apache configuration has it set to:
Header always append X-Frame-Options DENY
Removing it allowed it to work. Specifically in my case I was using iframe transport for jQuery with the jQuery file upload plugin to upload files in IE 9 and IE 10.
I know this question is super-old, but I wanted to mention that the above answer worked for me: setting the document.domain to be the same on each of the pages-- the parent page and the iframe page. However in my search, I did find this interesting article:
http://softwareas.com/cross-domain-communication-with-iframes
Note if you have a iframe with src='javascript:void(0)' then javascript like frame.document.location =... will fail with Access Denied error in IE. Was using a javascript library that interacts with a target frame. Even though the location it was trying to change the frame to was on the same domain as parent, the iframe was initially set to javascript:void which triggered the cross domain access denied error.
To solve this I created a blank.html page in my site and if I need to declare an iframe in advance that will initially be blank until changed via javascript, then I point it to the blank page so that src='/content/blank.html' is in the same domain.
Alternatively you could create the iframe completely through javascript so that you can set the src when it is created, but in my case I was using a library which reqired an iframe already be declared on the page.
Basically, this error occurs when the document in frame and outside of ii have different domains. So to prevent cross-side scripting browsers disable such execution.
if it is a domain issue (or subdomain) such as www.foo.com sending a request to www.api.foo.com
on each page you can set the
document.domain = www.foo.com
to allow for "cross-domain" permissions