I have configured my website on http2 but even after reading so many article i am unable to figure out few of its implementation.
I have removed common.css from header file of my website. and added the these lines to .htaccess file.
<IfModule http2_module>
#Check if there's a cookie saying the css has already been loaded:
SetEnvIf Cookie "cssloaded=1" cssloaded
#If no cookie, and it's an html file, then push the css file
#and set a session level cookie so next time it won't be pushed:
<filesMatch "\.([pP][hH][pP]?)">
Header add Link "</assets/css/common.css>;rel=preload;as=style" env=!cssloaded
Header add Set-Cookie "cssloaded=1; Path=/; Secure; HttpOnly" env=!cssloaded
</filesMatch>
</IfModule>
but My website is not loading common.css at all. it's breaking. My website is behind Apache server and website is fully build on codeIgniter.
I did add these to my common_head.php file too
<?php
header: header('Link: </assets/css/jquery-ui.css>; rel=preload; as=style,</assets/css/jquery.mCustomScrollbar.min.css>; rel=preload; as=style,</assets/css/slick.min.css>; rel=preload; as=style,</assets/css/slick-theme.min.css>; rel=preload; as=style,</assets/css/bootstrap.min.css>; rel=preload; as=style,</assets/css/common.css>; rel=preload; as=style,,</assets/css/jplayer.blue.monday.min.css>; rel=preload; as=style');
?>
Now i can see all the css file in inspect element and also can see initialtor Push/others but it is not applying on the page. Page is broken.
Apache server: 2.4.6
Please let me know where I am doing wrong?
That code looks familiar! Glad to know my blog post is proving useful :-)
I have removed common.css from header file of my website. and added the these lines to .htaccess file.
That’s where you went wrong. It needs to be referenced as normal in the HEAD and also pushed.
When the browser sees the common.css reference it will go to fetch it and see it’s already been pushed and just use the pushed resource.
Without reference the server will push it but the browser will just ignore it.
Note HTTP/2 Push is complicated and there’s lots of things like this where you can go wrong. See this post for more info: https://jakearchibald.com/2017/h2-push-tougher-than-i-thought/. Many are saying that it’s not worth the gains to use it, and the gains are questionable anyway as you can easily over push and cause the page to load slower rather than faster.
I did not explicitly set anywhere in nginx the x-frame-options to sameorigin but nginx is blocking the html page rendered inside an iframe. Tried specifying the domain in the X-Frame-Options but no luck. Giving several errors in the console if that helps. I read through them and tried fixes but not working.
https://preview.codecanyon.net/item/product-name/product-id
It previews my HTML page in an iframe.
The problem is not about X-Frame-Options but Content-Security-Policy also. Codecanyon set an CSP header that prevent the other sites can frame in their site. Even you allow all sites in your XFO header, they can block your site display in their website with CSP header.
But they are a market, they have to open a way for developer to include an iframe in their preview page. Seems they're not implemented a way for developer provide frame-src in preview page. So Codecanyon's CSP header is in Report only mode. All things is running fine although a lot of error you see from Chrome Developer Console.
By the way, you implemented an syntax error CSP header: unexpected punctuation at the start.
If it helps, I later figured out that setting frame-ancestors to that specific domain allowed that domain to show the page in an iframe. You can do that in the nginx config file.
I am working on a website, let say the website name is "https://website" (which is built on wordpress) in which I am getting the following error on console:
Uncaught DOMException: Blocked a frame with origin "https://website" from accessing a cross-origin frame.
at contents (https://website/wp-admin/load-scripts.php?c=1&load%5B%5D=jquery-core,jquery-migrate,jquery-ui-core,jquery-ui-widget,jquery-ui-mouse,jquery-ui-sortable,utils,underscore,wp-util,backbone,&load%5B%5D=moxiejs,plupload&ver=4.9.8:2:26921)
at Function.map (https://website/wp-admin/load-scripts.php?c=1&load%5B%5D=jquery-core,jquery-migrate,jquery-ui-core,jquery-ui-widget,jquery-ui-mouse,jquery-ui-sortable,utils,underscore,wp-util,backbone,&load%5B%5D=moxiejs,plupload&ver=4.9.8:2:3613)
at a.fn.init.n.fn.(anonymous function) [as contents] (https://website/wp-admin/load-scripts.php?c=1&load%5B%5D=jquery-core,jquery-migrate,jquery-ui-core,jquery-ui-widget,jquery-ui-mouse,jquery-ui-sortable,utils,underscore,wp-util,backbone,&load%5B%5D=moxiejs,plupload&ver=4.9.8:2:27001)
at b (https://website/wp-admin/load-scripts.php?c=1&load%5B%5D=postbox,thickbox,hoverIntent,common,admin-bar,wp-a11y,updates,plugin-install,svg-painter,heartbeat,wp-auth-check,shortcode,wp-ba&load%5B%5D=ckbone,media-models,wp-plupload,wp-mediaelement,wp-api-request,media-views,media-editor,media-audiovideo,mce-view,imgareaselect,&load%5B%5D=image-edit&ver=4.9.8:347:103)
at HTMLBodyElement.<anonymous> (https://website/wp-admin/load-scripts.php?c=1&load%5B%5D=postbox,thickbox,hoverIntent,common,admin-bar,wp-a11y,updates,plugin-install,svg-painter,heartbeat,wp-auth-check,shortcode,wp-ba&load%5B%5D=ckbone,media-models,wp-plupload,wp-mediaelement,wp-api-request,media-views,media-editor,media-audiovideo,mce-view,imgareaselect,&load%5B%5D=image-edit&ver=4.9.8:347:1306)
at HTMLBodyElement.dispatch (https://website/wp-admin/load-scripts.php?c=1&load%5B%5D=jquery-core,jquery-migrate,jquery-ui-core,jquery-ui-widget,jquery-ui-mouse,jquery-ui-sortable,utils,underscore,wp-util,backbone,&load%5B%5D=moxiejs,plupload&ver=4.9.8:3:12444)
at HTMLBodyElement.r.handle (https://website/wp-admin/load-scripts.php?c=1&load%5B%5D=jquery-core,jquery-migrate,jquery-ui-core,jquery-ui-widget,jquery-ui-mouse,jquery-ui-sortable,utils,underscore,wp-util,backbone,&load%5B%5D=moxiejs,plupload&ver=4.9.8:3:9173)
at Object.trigger (https://website/wp-admin/load-scripts.php?c=1&load%5B%5D=jquery-core,jquery-migrate,jquery-ui-core,jquery-ui-widget,jquery-ui-mouse,jquery-ui-sortable,utils,underscore,wp-util,backbone,&load%5B%5D=moxiejs,plupload&ver=4.9.8:3:11573)
at Object.a.event.trigger (https://website/wp-admin/load-scripts.php?c=1&load%5B%5D=jquery-core,jquery-migrate,jquery-ui-core,jquery-ui-widget,jquery-ui-mouse,jquery-ui-sortable,utils,underscore,wp-util,backbone,&load%5B%5D=moxiejs,plupload&ver=4.9.8:9:8275)
at HTMLDivElement.<anonymous> (https://website/wp-admin/load-scripts.php?c=1&load%5B%5D=jquery-core,jquery-migrate,jquery-ui-core,jquery-ui-widget,jquery-ui-mouse,jquery-ui-sortable,utils,underscore,wp-util,backbone,&load%5B%5D=moxiejs,plupload&ver=4.9.8:3:18991)
The above error is generated by clicking View Details section of wordpress plugins (as shown below):
This error seems to exist in every single wordpress plugins but it works when I open in a new tab but it doesn't work when I open in the same window.
Problem Statement:
I am wondering which file I need to modify in wordpress in order to solve this error. This error seems to exist in every wordpress plugins. As mentioned, it works in a new tab but fails to work in the same page.
I have a feeling I have to make some changes in the following file by seeing the error above (load-scripts.php, as the error is generated in that file) but not sure what line I need to add in order to make it work.
https://website/wp-admin/load-scripts.php
Something bad has happend to your WordPress admin interface.
The first thing to notice is that the error you have described is a well known problem as you may have already noticed: SecurityError: Blocked a frame with origin from accessing a cross-origin frame
Look at the first answer there:
You can't access an with different origin using JavaScript,
it would be a huge security flaw if you could do it. For the
same-origin policy browsers block scripts trying to access a frame
with a different origin.
Protocol, hostname and port must be the same of your domain, if you
want to access a frame.
The second thing to notice is what the "View details" button in the WordPress admin interface does: It opens a ThickBox containing and iframe which is showing remote contents quite often within an IFrame. How this works is ecactly described here: https://codex.wordpress.org/Javascript_Reference/ThickBox
load-scripts.php is an important WordPress core file loaded in the admin which is used to load JavaScript files without having to embed each of them. Those JavaScript files are usually added to your WordPress admin with the admin_enqueue_scripts() function (https://codex.wordpress.org/Plugin_API/Action_Reference/admin_enqueue_scripts).
As your problem is quite uncommon and the "View details" button for Plugins works almost everytime there are only two possibilities:
1. The "View Details" IFrame is usually loaded from the same location where your WordPress is - therefore you might have a problem such that the browser wants to load it from a different host
This happens if you have some misconfiguration within your WordPress installation and Thickbox tries to get an IFrame from a host which the Browser thinks is another host. Configure WordPress correctly.
2. You have a badly programmed plugin or theme which is injecting a script causing this problem
Solution: Deactivate your theme and all your plugins one-by-one and see if the error still exists. This way you can find out the modification which causes the problem and maybe do a bug request to the plugin developers then.
It is almost 100% sure that a single plugin, theme or misconfiguration is causing this problem.
For posterity, chances are your X-Frame-Options have either been set to deny by the server or a configuration was appended by another plugin, but the blocked frame issue may happen when your server has not been configured correctly or was configured with strict policies to prevent any sort of access to cross-origin frames. Since every plugin is affected when viewing the Details link, my answer coincides with what #Blackbam has explained regarding how it functions by bringing up a thickbox and uses an i-frame when explaining why they all don't seem to appear.
I am wondering which file I need to modify in WordPress in order to
solve this error. This error seems to exist in every wordpress
plugins. As mentioned, it works in a new tab but fails to work in the
same page.
So, for this particular case I don't believe it's necessarily a WordPress issue but a hosting server configuration and, depending on how much access you have to the server or wherever you're building the website, will determine what you can do to solve this error or whether or not you'll need to contact support to help you resolve it.
(Since this answer is simply added for posterity, please excuse the present tense references used as I realize it's been 3 years since this was asked)
Solutions:
There are two options that may work for you, and will vary depending on your server and your user access.
Solution 1: Adding permissions by modifying the .htaccess file
If your webhosting server is running on Apache or other supported web server, you can try adding the lines below to the .htaccess file:
<ifModule mod_headers.c>
Header set Strict-Transport-Security "max-age=31536000" env=HTTPS
Header always set X-Frame-Options "sameorigin"
Header setifempty Referrer-Policy: same-origin
</ifModule>
For syntax, you can refer to to this page. But as another option, instead of setting X-Frame-Options to "sameorigin" you can also specify a particular domain so as to preserve the security feature if preferred, such as:
Header always append X-Frame-Options "ALLOW-FROM website.com/*"
And replacing "website.com/*" with the domain you would like to permit, noting the space between ALLOW-FROM and the URL as further explained here. If you have other plugins installed that have modified your .htaccess file, be sure to place this entry above any Wordpress created entry as the .htaccess file is loaded in order and also note that it may not be supported in all browsers. Now, depending on the server security policies, if this doesn't work, then you'll have to move on to the next solution.
Solution 2: Modify your server configuration
Though I'm only including instructions for an Apache server from here as reference, this page includes configurations for Nginx, IIS, HAProxy, and Express as well. A full explanation can be found here if you have access to WHM and/or are running virtual servers and will require root access.
Log into the web server and look for the following file:
/etc/apache2/conf/httpd.conf
# or you can also create a new file named 'include.conf' if it
# doesn't already exist
/etc/apache2/conf.d/userdata/{USERNAME}/{DOMAIN-NAME}/include.conf
If the file exists, you can either comment out the line if it's set to DENY to disable the restriction or add the line below to the newly created configuration file:
<ifModule mod_headers.c>
Header set Strict-Transport-Security "max-age=31536000" env=HTTPS
Header always set X-Frame-Options "sameorigin"
</ifModule>
You'll then need to rebuild the configuration and restart the Apache server.
You can rebuild by running the command
/usr/local/cpanel/scripts/rebuildhttpdconf
Then restart with
/usr/local/cpanel/scripts/restartsrv_httpd
Without the same-origin setting, even though Wordpress is installed on the server, the jquery requests are being blocked as part of preventing any embedding of content from other sites as well. Read more about Secure Headers from OWASP
I have built a widget using the Fat-Free Framework for a client that should make their life easier, but they also requested that their website is created using Wix. I thought it would be easy to embed this F3 site within the Wix site using their embedding plugins (there are built-in and plug-in versions).
The problem is that regardless of the answers I have received so far on SO and other sites, I still get an X-Frame-Options is set to SAMEORIGIN error. I have tried the following:
header_remove() php command
header('X-Frame-Options: GOFORIT') php command (GOFORIT is for anything but SAMEORIGIN and DENY)
adding &output=embed to the link (this didn't work with F3)
adding the following htaccess code:
Header always append X-Frame-Options SAMEORIGIN
Header set Access-Control-Allow-Origin: "http://editor.wix.com"
Header set Access-Control-Allow-Origin: "http://www.wix.com"
I am afraid that the Wix embed plug-in will be a bit limited and I won't be able to change much on that end. Any ideas what to try next? Is there some configuration for F3 that will help this problem or am I using the PHP code wrong? Does anything need to be configured on the Wix site? Thanks for any help.
Try to set the XFRAME option for the framework:
$f3->set('XFRAME','GOFORIT');
https://github.com/bcosca/fatfree-core/blob/master/base.php#L2153
I didn't look into my .htaccess file. There was the line Header append X-FRAME-OPTIONS "SAMEORIGIN" in there along with some allows for Wix. Simply removing the append line allowed it to be embed.
I am trying to create a type of font repository for use on my websites, so that I can call to any font in the repository in my css without any other set-up. To do this I created a subdomain on which I placed folders for each font in the repository that contained the various file types for each font. I also placed a css file called font-face.css on the root of the subdomain and filled it with #font-face declarations for each of the fonts, the fonts are linked with an absolute link so that they can be used from anywhere.
My issue is that it seems that I can only use the fonts on that subdomain where they are located, on my other sites the font does not show. Using firebug I determined that the font-face.css file was successfully being linked to and loaded. So why does the font not correctly load? Is there protection on the font files or something? I am using all fonts that I should be allowed to do this with, so I don't see why this is occurring. Maybe it is an apache issue, but I can download the font just fine when I link to it.
Oh, and just to clarify, I am not violating any copyrights by setting this up, all the fonts I am using are licensed to allow this sort of thing. I would however like to set up a way that only I can have access to this repository of fonts but that's another project.
This is because Firefox (from your mention of Firebug) thinks cross-domain, even subdomain, Web font embedding is a bad idea.
You can convince it to load fonts from your subdomain by adding this to the top-level .htaccess file of the subdomain where your fonts are being served (updated to adapt code from the same file in HTML5 Boilerplate):
<FilesMatch "\.(ttf|ttc|otf|eot|woff)$">
<IfModule mod_headers.c>
Header set Access-Control-Allow-Origin "*"
</IfModule>
</FilesMatch>
In response to this:
I would however like to set up a way that only I can have access to this repository of fonts but that's another project.
The W3C spec for Access-Control-Allow-Origin doesn't say anything more than either a wildcard "*" or a specific domain. So far, I've found this SO answer which suggests validating the Origin header, but I think that's a Firefox-only header. I'm not sure about other browsers (they don't even need the .htaccess trick above for cross-domain Web fonts to work).
Another way to fix this in Firefox is to embed the font directly into the css file using base64 encoding. Especially nifty if you don't have access to some of the configuration mentioned above.
You can generate the necessary code on fontsquirrel.com: in the font-face Kit Generator choose expert mode, scroll down and select Base64 Encode under CSS Options - the downloaded Font-Kit will be ready to plug and play.
This also has the fringe benefit of reducing page load time because it requires one less http request.
If you do not want to allow resources from all domains but only from sub domain of your site, you should do it like:
# Allow font, js and css to be loaded from subdomain
SetEnvIf Origin "http(s)?://(.+\.)?(example\.com)$" ORIGIN_DOMAIN=$0
<IfModule mod_headers.c>
<FilesMatch "\.(eot|font.css|otf|ttc|ttf|woff|js|png|jpg|jpeg|gif)$">
Header set Access-Control-Allow-Origin %{ORIGIN_DOMAIN}e env=ORIGIN_DOMAIN
</FilesMatch>
</IfModule>
Source: http://www.webspeaks.in/2015/01/wordpress-allow-cross-domain-resources.html
Using http://www.fontsquirrel.com/fontface/generator in "expert" mode and choosing base64 as an option returned a stylesheet.css with the necessary base64 encoded data to use in our stylesheet. Seems to work in all browsers we've tested except IE8.
We run into this issue most when applying themes to 3rd party tools like salsa petition where we're forced to host the font.
Thanks for all the help everyone!