Develop Reference

X-frame origins block, is there an alternative to embedding? VUE JS [duplicate]

I am developing a web page that needs to display, in an iframe, a report served by another company's SharePoint server. They are fine with this.
The page we're trying to render in the iframe is giving us X-Frame-Options: SAMEORIGIN which causes the browser (at least IE8) to refuse to render the content in a frame.
First, is this something they can control or is it something SharePoint just does by default? If I ask them to turn this off, could they even do it?
Second, can I do something to tell the browser to ignore this http header and just render the frame?

If the 2nd company is happy for you to access their content in an IFrame then they need to take the restriction off - they can do this fairly easily in the IIS config.
There's nothing you can do to circumvent it and anything that does work should get patched quickly in a security hotfix. You can't tell the browser to just render the frame if the source content header says not allowed in frames. That would make it easier for session hijacking.
If the content is GET only you don't post data back then you could get the page server side and proxy the content without the header, but then any post back should get invalidated.

UPDATE: 2019-12-30
It seem that this tool is no longer working! [Request for update!]
UPDATE 2019-01-06: You can bypass X-Frame-Options in an <iframe> using my X-Frame-Bypass Web Component. It extends the IFrame element by using multiple CORS proxies and it was tested in the latest Firefox and Chrome.
You can use it as follows:
(Optional) Include the Custom Elements with Built-in Extends polyfill for Safari:
<script src="https://unpkg.com/#ungap/custom-elements-builtin"></script>
Include the X-Frame-Bypass JS module:
<script type="module" src="x-frame-bypass.js"></script>
Insert the X-Frame-Bypass Custom Element:
<iframe is="x-frame-bypass" src="https://example.org/"></iframe>

The X-Frame-Options header is a security feature enforced at the browser level.
If you have control over your user base (IT dept for corp app), you could try something like a greasemonkey script (if you can a) deploy greasemonkey across everyone and b) deploy your script in a shared way)...
Alternatively, you can proxy their result. Create an endpoint on your server, and have that endpoint open a connection to the target endpoint, and simply funnel traffic backwards.

Yes Fiddler is an option for me:
Open Fiddler menu > Rules > Customize Rules (this effectively edits CustomRules.js).
Find the function OnBeforeResponse
Add the following lines:
oSession.oResponse.headers.Remove("X-Frame-Options");
oSession.oResponse.headers.Add("Access-Control-Allow-Origin", "*");
Remember to save the script!

As for second question - you can use Fiddler filters to set response X-Frame-Options header manually to something like ALLOW-FROM *. But, of course, this trick will work only for you - other users still won't be able to see iframe content(if they not do the same).

Cache is not cleared in Google Chrome

When I deploy the version I will add the number as a query string with the JavaScript and CSS file like following?
'app/source/scripts/project.js?burst=32472938'
I am using the above to burst the cache in the browser.
But in Firefox, I am getting the latest script that I have modified.
But in Chrome, I am not getting the latest script that I have modified. Instead of that, I am getting the old one.
But in the developer console, I am seeing the burst number which is modified in latest.

According to the Google documentation, the best way to invalidate and reload the file is to add a version number to the file name and not as a query parameter:
'app/source/scripts/project.32472938.js'
Here is a link to the documentation:
https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching#invalidating_and_updating_cached_responses
Another way is to use an ETag (validation token):
https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching#validating_cached_responses_with_etags
Here is how you would set up an ETag with Nginx:
http://nginx.org/en/docs/http/ngx_http_core_module.html#etag
And lastly, a tutorial about browser caching with Nginx and ETag:
https://www.digitalocean.com/community/tutorials/how-to-implement-browser-caching-with-nginx-s-header-module-on-centos-7#step-2-%14-checking-the-default-behavior

I'm uncertain of whether this still applies these days, but there were some cases in the past where proxies could cause a query-string value to be ignored for caching purposes. There's an article from 2008 that discussed the idea that query-string values weren't ideal for the purpose of breaking caching, and that it was better to revise the filename itself -- so, referencing project_32472938.js instead of using the query-string.
(I've also seen, in places, some discussion of unusual cases where certain clients were not seeing these updates, but it seemed to be inconsistent -- not tied to Chrome, necessarily, but more likely tied to a specific installation of Chrome on a specific machine. I'd certainly recommend checking the site on another computer to see if the issue is repeated there, as you could at least narrow down to whether it's Chrome in general, or your specific install of Chrome that is having problems.)
All that said, it's been quite a while since 2008, and that may not be applicable these days. However, if it continues to be a problem -- and you can't find a solution to the underlying problem -- it at least offers a method use to circumvent it.

I don't think that Chrome actually causes the problem, because
it would break almost all web applications
(eg: https://www.google.com/search?q=needle)
It could be that your deployment was a bit delayed, eg.
Start install new scripts
Check with Chrome (receives old version on new ID)
Install finishes
You try with Firefox (receives new version)
Chrome still shows old version because it cached the old script with new ID
Or you have a CDN like Azure between your web server and your browser.
With standard settings Azure CDN ignores the query string for the caching hash.

try those meta tags:
<meta http-equiv="cache-control" content="max-age=0" />
<meta http-equiv="cache-control" content="no-cache" />
<meta http-equiv="expires" content="0" />
<meta http-equiv="expires" content="Tue, 01 Jan 1980 1:00:00 GMT" />
<meta http-equiv="pragma" content="no-cache" />

i not sure , but for try...
google crome always ignore it..
you need to add a '?random.number' or "?date.code" to every link each time a url is pressed on your website.
eg if 'myhomepage.html?272772' is stored in the cache, then by generating a new random number eg 'myhomepage.html?2474789', google chrome will be forced to look for a new copy.

Internet Explorer 11 D3 javascript error - SCRIPT5 Access is denied

I'm trying to open this D3 along with this json on IE11, but the screen is just blank. When I Inspect Element to check console, it shows this error :
SCRIPT 5 : Access is denied.
File: d3.min.js, Line: 1, Column: 10922
I tried many fixes like lowering security, allowing active content, adding specific tags in the html etc. and also looked at similar stackoverflow questions, but no luck.
It works fine in Firefox though.
How do I get it to run in IE?

Solution - I put the files on Sharepoint server, and it worked.
IE does not allow linking to files on local desktop due to some policy, but if it's part of IIS, it's fine.

This is inner security of IE 11. Microsoft auto detects 'harmful' script and file and denies access. Basically, You need to check the options tab, or try even try using:
<meta http-equiv="X-UA-Compatible" content="IE=edge" />
Tty also permission settings and make sure add-ons are allowed on your IE.

How do I prevent caching on a website?

Within a website in development, we have it templated as a master page that contains the head of the webpage, then a header and body div that loads in content dynamically. Basically, I'm trying to prevent caching on all the pages loaded in dynamically.
Browsers would be IE8 onwards.

As you said you should only be doing that if the website is in development or the content really needs to be loaded fresh every time. Internet Explorer supports some meta tags that can do what you need, specifically
<META HTTP-EQUIV="Pragma" CONTENT="no-cache">
<META HTTP-EQUIV="Expires" CONTENT="-1">
Click here for more information
If you ever want to test in firefox, you could try out this plugin

If you are using Google Chrome to develop, there are an option that let you cache free when dev tools is open, but if you want a simple trick is just to pass a timestamp in a query string during your request. Something like:
http://localhost/path/to/project/?nocache=74567363
If you are using some framework that helps you to handle with the includes like AngularJS ou BackboneJS, make the redirects with:
var myUrl = 'http://localhost/path/to/project/?nocache=';
var timestamp = (new Date()).getTime();
window.location.href = myUrl + timestamp;

How may I disable an http-equiv refresh in JavaScript?

I'm building a status page which should be refreshed periodically.
So, I've had a http-equiv refresh in the <head> section in order to refresh the page every minute :
<meta http-equiv="Refresh" id="refresh" content="60"/>
But, for browser supporting JavaScript, I would like to send an Ajax request checking if the page should be refreshed or not. And so, I would like to disable that http-equiv refresh in JavaScript (because it's Ajax which will do the work).
I tried to remove the tag using JavaScript/PrototypeJs but that doesn't work :
$('refresh').remove();
It seems that the browser keep trace of that timer and doesn't take care of that DOM update.
Any idea ?

Not exactly sure, but maybe:
<noscript>
<meta http-equiv="Refresh" id="refresh" content="60"/>
</noscript>

This would be better handled on the server. There are a number of tools to let you reliably check to see if the browser supports JS (BrowserHawk is one that comes to mind) or you can check the SupportsECMAScript (in ASP.NET) property of the Browser object and write out different code if the browser supports JS.

I don't think there's a way of disabling the http-equiv refresh.
Is the status page the first page in your app? If not, then why not get the capabilities of the client up front before requesting the status page? If it is then you might have to inject a UI-less page that grabs the capability of the browser and instantly post back to the real status page. All this assumes that you're not willing to use the user agent string in the HTTP Header to get the browser capability.