If I create an iframe like this:
var dialog = $('<div id="' + dialogId + '" align="center"><iframe id="' + frameId + '" src="' + url + '" width="100%" frameborder="0" height="'+frameHeightForIe8+'" data-ssotoken="' + token + '"></iframe></div>').dialog({
How can I fix the error:
Refused to display 'https://www.google.com.ua/?gws_rd=ssl' in a frame because it set 'X-Frame-Options' to 'SAMEORIGIN'.
with JavaScript?
You can't set X-Frame-Options on the iframe. That is a response header set by the domain from which you are requesting the resource (google.com.ua in your example). They have set the header to SAMEORIGIN in this case, which means that they have disallowed loading of the resource in an iframe outside of their domain. For more information see The X-Frame-Options response header on MDN.
A quick inspection of the headers (shown here in Chrome developer tools) reveals the X-Frame-Options value returned from the host.
X-Frame-Options is a header included in the response to the request to state if the domain requested will allow itself to be displayed within a frame. It has nothing to do with javascript or HTML, and cannot be changed by the originator of the request.
This website has set this header to disallow it to be displayed in an iframe. There is nothing that can be done in a client-side web browser to stop this behaviour.
Further reading on X-Frame-Options
In case you are in control of the Server that sends the content of the iframe you can set the setting for X-Frame-Options in your webserver.
Configuring Apache
To send the X-Frame-Options header for all pages, add this to your site's configuration:
Header always append X-Frame-Options SAMEORIGIN
Configuring nginx
To configure nginx to send the X-Frame-Options header, add this either to your http, server or location configuration:
add_header X-Frame-Options SAMEORIGIN;
No configuration
This header option is optional, so if the option is not set at all, you will give the option to configure this to the next instance (e.g. the visitors browser or a proxy)
source: https://developer.mozilla.org/en-US/docs/Web/HTTP/X-Frame-Options
Since the solution wasn't really mentioned for the server side:
One has to set things like this (example from apache), this isn't the best option as it allows in everything, but after you see your server working correctly you can easily change the settings.
Header set Access-Control-Allow-Origin "*"
Header set X-Frame-Options "allow-from *"
and if nothing helps and you still want to present that website in an iframe consider using X Frame Bypass Component which will utilize a proxy.
not really... I used
<system.webServer>
<httpProtocol allowKeepAlive="true" >
<customHeaders>
<add name="X-Frame-Options" value="*" />
</customHeaders>
</httpProtocol>
</system.webServer>
The X-Frame-Options HTTP response header can be used to indicate whether or not a browser should be allowed to render a page in a <frame>, <iframe> or <object>. Sites can use this to avoid clickjacking attacks, by ensuring that their content is not embedded into other sites.
For More Information:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options
I have an alternate solution for this problem, which I am going to demonstrate by using PHP:
iframe.php:
<iframe src="target_url.php" width="925" height="2400" frameborder="0" ></iframe>
target_url.php:
<?php
echo file_get_contents("http://www.example.com");
?>
This is also a new browser security feature to prevent phishing and other security threats. For chrome, you can download an extension to prevent the browser from denying the request.
I encountered this issue while working on WordPress locally.
I use this extension https://chrome.google.com/webstore/detail/ignore-x-frame-headers/gleekbfjekiniecknbkamfmkohkpodhe
(I'm resurrecting this answer because I would like to share the workaround I created to solve this issue)
If you don't have access to the website hosting the web page you want to serve within the <iframe> element, you can circumvent the X-Frame-Options SAMEORIGIN restrictions by using a CORS-enabled reverse proxy that could request the web page(s) from the web server (upstream) and serve them to the end-user.
Here's a visual diagram of the concept:
Since I was unhappy with the CORS proxies I found, I ended up creating one myself, which I called CORSflare: it has been designed to run in a Cloudflare Worker (serverless computing), therefore it's a 100% free workaround - as long as you don't need it to accept more than 100.000 request per day.
You can find the proxy source code on GitHub; the full documentation, including the installation instruction, can be found in this post of my blog.
For this purpose you need to match the location in your apache or any other service you are using
If you are using apache then in httpd.conf file.
<LocationMatch "/your_relative_path">
ProxyPass absolute_path_of_your_application/your_relative_path
ProxyPassReverse absolute_path_of_your_application/your_relative_path
</LocationMatch>
The solution is to install a browser plugin.
A web site which issues HTTP Header X-Frame-Options with a value of DENY (or SAMEORIGIN with a different server origin) cannot be integrated into an IFRAME... unless you change this behavior by installing a Browser plugin which ignores the X-Frame-Options Header (e.g. Chrome's Ignore X-Frame Headers).
Note that this not recommended at all for security reasons.
The way around this is to grab the HTML server side, add a <base href="..." /> so any relative and absolute paths still work.
Here's my node route
/api/url/:url
export default async function handler(req, res) {
const url = `https://${req.query.url}`;
const response = await fetch(url);
const urlContents = await response.text();
// Prepend the base to make sure all relative and absolute paths work
const urlContentsWithHead = `<base href='${url}' /></head>${urlContents}`;
res.status(200).send(urlContentsWithHead);
}
You can then use this route directly in the iframe
<iframe src={`/api/url/${url}`} />
Oddly when I tried to do this "properly" by putting the <base /> element just before the closing </head> tag by using a replace, it didn't work. But putting the base before all of the markup (even the <html>) seemed to work.
Not sure if there will be any adverse affects 🤷
you can set the x-frame-option in web config of the site you want to load in iframe like this
<httpProtocol>
<customHeaders>
<add name="X-Frame-Options" value="*" />
</customHeaders>
</httpProtocol>
You can not really add the x-iframe in your HTML body as it has to be provided by the site owner and it lies within the server rules.
What you can probably do is create a PHP file which loads the content of target URL and iframe that php URL, this should work smoothly.
you can do it in tomcat instance level config file (web.xml)
need to add the 'filter' and filter-mapping' in web.xml config file.
this will add the [X-frame-options = DENY] in all the page as it is a global setting.
<filter>
<filter-name>httpHeaderSecurity</filter-name>
<filter-class>org.apache.catalina.filters.HttpHeaderSecurityFilter</filter-class>
<async-supported>true</async-supported>
<init-param>
<param-name>antiClickJackingEnabled</param-name>
<param-value>true</param-value>
</init-param>
<init-param>
<param-name>antiClickJackingOption</param-name>
<param-value>DENY</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>httpHeaderSecurity</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
Related
I need to use Stripe in my application but I keep getting the error below in the browser console.
Content Security Policy: The page’s settings blocked the loading of a resource at inline (“script-src”).
I've tried to fix it by setting a rule in Content-Security-Policy but I cannot make it work.
<meta http-equiv="Content-Security-Policy"
content="script-src 'self' https://js.stripe.com />
<script type="text/javascript" src="https://js.stripe.com/v3/"></script>"
I run the code in localhost and I am using Firefox Developer Edition.
How can I fix this error?
To allow a script resource at inline, your CSP needs to have 'unsafe-inline' set. But as you can understand from the name, this is unsafe and should be avoided if possible. Rather see if you can move the script code to a separate file.
Also, it seems like you are hitting a problem with a CSP and try to solve it by adding another one. Another CSP can only make it stricter, you can't allow something restricted by the original CSP. You should see if there is a CSP in a response header and modify that one instead.
I am setting content security policy as
<meta charset="UTF-8" http-equiv="content-security-policy" content="object-src 'self' data:" /> and it render as
I am trying to render a base64 encode pdf using object tag in vue3 as shown
<object
class="pdfObject"
:data="'data:application/pdf;base64,' + props.encodedPdf"
type="application/pdf"
></object>
and getting the below error
The most likely explanation is that two policies are served. The other one is most likely found in a response header and sets the directive "object-src 'none';". Content needs to pass all policies, and if another policy allows nothing you'll need to remove or modify that policy first.
I was using I3 service for authentication and CSP headers 'object-src' was set from their end. I had to update the header there.
I need to disable caching for single files in all browsers.
I have a website that generates small video clips. There is a preview stage where the results can be watched.
An mp4 called preview.mp4 is displayed. When the user goes back, edits the video and wants to preview it again, the old preview.mp4 is being displayed even though the file on the server is changed.
How can I prevent the caching of this video file? Or what are the other ways to fix it?
Note: it's a single page application so I don't reload any HTML files. Only PHP content. Hence the headers I set, are not useful in this scenario:
<meta http-equiv="X-UA-Compatible" content="IE=Edge"/>
<meta http-equiv="cache-control" content="no-store" />
Thanks.
It's not the web page itself you should be concerned about, but the mp4 file which is downloaded and cached separately.
Ensure the response headers of the mp4 file prevent browser caching.
Cache-Control: no-cache
Hence the headers I set, are not useful in this scenario:
<meta http-equiv="cache-control" content="no-store" />
There problem here is that those are not headers.
They are HTML elements (which are part of the HTML document, which is the body of the HTTP response) which attempt to be equivalent to HTTP headers … and fail.
You need to set real HTTP headers, and you need to send them with the video file (rather than the HTML document).
The specifics of how you do that will depend on the HTTP server you use.
Further reading:
Caching in the HTTP specification
Caching Tutorial for Web Authors and Webmasters
Caching Guide in the Apache HTTPD manual
How to Modify the Cache-Control HTTP Header When You Use IIS
Try adding a cache key
preview.mp4?cachekey=randNum
Where randNum can be a timestamp or you use a random number generator to generate randNum.
Within HTML if the entire site is served over HTTPS, and it makes reference to the following:
<img src="../images/Sexy_Ben.jpeg" />
Does that mean that the file in question will be served over HTTP or HTTPS?
Thanks,
HTTPS, relative paths use the same protocol that the HTML page was loaded with.
How do I define
<meta http-equiv="cache-control" content="no-cache" />
in HTML5? It is no longer valid according to the W3C Validator and the documentation.
Putting caching instructions into meta tags is not a good idea, because although browsers may read them, proxies won't. For that reason, they are invalid and you should send caching instructions as real HTTP headers.
In the beginning of code you need to use this:
<!DOCTYPE html>
<html manifest="cache.manifest">
...
Then create cache.manifest file with content of what you want to cache i.e
CACHE MANIFEST
# 2010-06-18:v2
# Explicitly cached 'master entries'.
CACHE:
/favicon.ico
index.html
stylesheet.css
images/logo.png
scripts/main.js
# Resources that require the user to be online.
NETWORK:
*
# static.html will be served if main.py is inaccessible
# offline.jpg will be served in place of all images in images/large/
# offline.html will be served in place of all other .html files
FALLBACK:
/main.py /static.html
images/large/ images/offline.jpg
A manifest can have three distinct sections: CACHE, NETWORK, and FALLBACK.
CACHE:
This is the default section for entries. Files listed under this header (or immediately after the CACHE MANIFEST) will be explicitly cached after they're downloaded for the first time.
NETWORK:
Files listed in this section may come from the network if they aren't in the cache, otherwise the network isn't used, even if the user is online. You can white-list specific URLs here, or simply "", which allows all URLs. Most sites need "".
FALLBACK:
An optional section specifying fallback pages if a resource is inaccessible. The first URI is the resource, the second is the fallback used if the network request fails or errors. Both URIs must from the same origin as the manifest file. You can capture specific URLs but also URL prefixes. "images/large/" will capture failures from URLs such as "images/large/whatever/img.jpg".
There is no HTML solution. Mozilla's application cache (cache.manifest) is deprecated. The application cache site says:
This feature has been removed from the Web standards. Though some browsers may still support it, it is in the process of being dropped. Avoid using it and update existing code if possible. ... Use Service Workers instead.
Apart from that, I suggest you use HTTP Cache-Control to solve cache issues.
There isn't an HTML solution, because it's not a markup problem. Caching is an action on the resource, not part of the resource definition itself.
As others have said, HTTP headers are the best way to control caches, because these are observed by all caches - <meta> tags are only observed by browser caches. These should be set by your server / web framework.
That said, I wouldn't be surprised if browsers still observe <meta http-equiv="cache-control" content="no-cache"> for pages with the HTML5 doctype.