UPDATE
After enabling direcorty listing it seems to have worked but now im running into another error.
Resource interpreted as Stylesheet but transferred with MIME type text/html
I'm trying to rewrite a URL to take content from the absolute directory.
Let's assume my URL was https://somesite.com/a <-- absolute path
This directory consist of files like index.html, contact.html and folders like css,js,img
But i want to access this directory with a URL like https://somesite.com/a/somename/index which should take me to https://somesite.com/a/index but it should also keep the parameter somename in the URL therefore redirecting is not an option, this is because i need to use the Referrer Url later onwards from backend code.
My Rule
<rule name="StoreRewrite" stopProcessing="true">
<match url="^a/([^/]+)/([^/]+)" />
<conditions>
<add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />
<add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" />
</conditions>
<action type="Rewrite" url="a/{R:2}" />
</rule>
The above redirect works but it doesn't load the additional content inside the html files, like js,css files which are all relative to the html file.
The below error is show when i enter the url https://somesite.com/a/someprofile/contact
The page from a\contact is displayed but not its relative content.
The console is filled with this error
Failed to load resource: the server responded with a status of 403 (Forbidden)
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>
Normally for .js and .css file we will append a version during build like
xx.js?v=123, and then after website deploy, we can get the new version of js and CSS. But I don't see a place talking about how to make the index.html file upgrade when website deployment happen. And we do see in IE that the HTML content should have been changed but it still use the old HTML content.
One solution I find from google is to
<meta http-equiv="Cache-control" content="no-cache">
However, I am not sure whether this is the best solution?
Yes, that is the correct way. You have to set the Cache-Control header to let the browsers know that they don't have to cache any content for that request.
<meta http-equiv="Cache-control" content="no-cache, no-store, must-revalidate">
<meta http-equiv="Pragma" content="no-cache">
(Pragma & Cache-Control is one and the same thing but from the different HTTP specification. See the answer here: Difference between Pragma and Cache-control headers?)
See one of the related answer here: How to burst yeoman index.html cache
As mentioned in the comments it's really the server configuration you want to be looking at but you haven't mentioned your setup. We run our AngularJS site with a .NET backend using IIS.
We update our site regularly and have had issues in the past with JS and CSS resources caching but we've solved it through the following settings:
Build
We use gulp to build our AngularJS application and as part of that we append a version number to the querystring of our main application CSS and Javascript files that change frequently. For example:
<link href="css/default.min.css?v=2" rel="stylesheet" />
Server Configuration
In the root web.config we specify that we don't want to the index.html to cache by setting the cache-control, Pragma and Expires request headers as well as the max-age to 0.
<location path="index.html">
<system.webServer>
<staticContent>
<clientCache cacheControlMode="DisableCache" cacheControlMaxAge="0.00:00:00" />
</staticContent>
<httpProtocol>
<customHeaders>
<add name="Cache-Control" value="no-cache, no-store, must-revalidate" />
<add name="Pragma" value="no-cache" />
<add name="Expires" value="-1" />
</customHeaders>
</httpProtocol>
</system.webServer>
</location>
References:
IIS Client Cache: https://learn.microsoft.com/en-us/iis/configuration/system.webserver/staticcontent/clientcache
Cache-Control HTTP Header : https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control
Pragma HTTP Header: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Pragma
Expires HTTP Header: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Expires
By setting content value to 0, browsers will always load the page from the web server.
<meta http-equiv="expires" content="0">
You can specify IIS from the specific sites advanced settings that preloading is not enabled. Your site performance will however suffer. Also check that the application pool for the specific website has integrated pipeline mode on and .NET CLR version.
Just add this to nginx file:
location ~ \.html$ {
add_header Cache-Control no-store;
}
A while ago I designed a app that would insert a meta tag into my pages so I could test them with internet explorer in different document modes. My solution, though functional, was klugy. Assuming IIS7 and explorer as server/client, what are some light weight solutions for quickly adding a meta tag programmaticly for a short time.
You can do that very easily using URL Rewrite and leverage the Outbound Rewrite capabilities. Once it is installed just add a web.config to the application folder like the following and it will automatically insert a META tag to every HTML page that is served by the application. You can obviously add more conditions and make that only rewrite for pages you want (see preConditions) as well as capture data from headers or other places and add it in the response.
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<rewrite>
<outboundRules rewriteBeforeCache="true">
<rule name="WriteMETA" preCondition="MatchHTML">
<match pattern="<head>" occurrences="1" />
<action type="Rewrite" value="<head>
<meta name='author' content='Carlos Aguilar Mares' />
" />
</rule>
<preConditions>
<preCondition name="MatchHTML" patternSyntax="Wildcard">
<add input="{RESPONSE_CONTENT_TYPE}" pattern="text/html" />
</preCondition>
</preConditions>
</outboundRules>
</rewrite>
</system.webServer>
</configuration>
Chrome from version 16 became pretty strict on content-disposition headers having unquoted commas. While most sites out on the web will face user pressure to fix their servers this is not so easy for small or in-house intranet applications that no one is quite willing to touch.
Thread on Chrome's forum about the issue, what works and what doesn't.
Short answer is that the Content-Disposition header, if included, needs to either not have commas in the filename or have filenames quoted.
We have one such system handling document management, touching the codebase is NOT an option, but any files with commas in their names will throw an error in Chrome. how can I fix this?
Doing a bit of a Jeopardy! thing here but not 100% confident on my answer and would appreciate comments/alternatives
You could do this using IIS's URL Rewrite module which can also work on headers.
The key will be to match on Content-Disposition which includes filename= and doesn't have quotemarks for the filename.
<system.webServer>
<rewrite>
<outboundRules>
<rule name="Chrome Comma Fix">
<match serverVariable="RESPONSE_Content_Disposition" pattern="^(.*)(filename=)(?!")([^"]*)(;.*)?$" />
<action type="Rewrite" value="{R:1}{R:2}"{R:3}"{R:4}" />
</rule>
</outboundRules>
</rewrite>
</system.webServer>
I haven't yet tested this though.