.htaccess do not preload files on Ajax calls - php

I have some website running with PHP. In my .htaccess I have added the following directives:
<FilesMatch "index.php">
Header add Link "</css/bootstrap.min.css>; rel=preload; as=style"
</FilesMatch>
The websites main content is solely called via the index.php, like this https://somedomain.com or https://somedomain.com/?feature=a.
Within the website I am using Ajax to call further data, from URIs like https://somedomain.com/ajax.php?load=this.
Recently Google Chrome started throwing warnings in the dev console with every Ajax call that is done, like that:
The resource was preloaded using link preload but not used within a few seconds from the window's load event. Please make sure it has an appropriate as value and it is preloaded intentionally.
Is that a bug in Chrome or is there something wrong with my .htaccess?
Thank you.

Seems like the issue was a bug in Google Chrome. Since today Chrome doesn't throw the warning anymore.

Related

Implementing http2 push method on apache php

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.

Blocked a frame with origin from accessing a cross-origin frame in wordpress

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

The 'Access-Control-Allow-Origin' header has a value that is not equal to the supplied origin

I am trying to login with ajax to an API and I get this error:
XMLHttpRequest cannot load. The 'Access-Control-Allow-Origin' header
has a value that is not equal to the supplied origin. Origin
'http://localhost' is therefore not allowed access.
I read all about this error, all over the internet, and I've tried all the solutions I could find online. I modified the .htaccess and apache httpd configuration file according to the CORS instructions here: http://enable-cors.org/server_apache.html
Access-Control-Allow-Origin: *
Nothing seems to be working. I'd really appreciate if you guys can help me out with this. Thank you!
You have to set Access-Control-Allow-Origin header to * or specified value http://localhost
You can do this through:
1- Your code
2- .htaccess file
3- Server config (restart web server required)
Here is the link that show how to do it on apache
http://access-control-allow-origin-guide.com/enable-cors-on-apache-linux/
As added browser security, unless the API allows cross-browser origins in the the return responses header there is no way around this.
The browsers are blocking it, there is a plugin to allow for chrome but it is not realistic to depend on browser plugin to allow end user requests,
Try and reach out to the API provider and see if they can look into updating the header in the response.
It is a CORS issue:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS
i use htaccess file for load JSON data in different hosting, and its works but
it have to put inside the public html root of our web hosting for example
uploading .htaccess into --> (https://freehostingsomewhere.com/)
then inside .htaccess
<FilesMatch "\.(ttf|otf|eot|woff|jpg|png|jpeg|gif|js|json|html|css)$">
<IfModule mod_headers.c>
Header set Access-Control-Allow-Origin "http://localhost"
</IfModule>
</FilesMatch>
in here i use http://localhost to development and it works,
maybe if i have another web host just change it into that url, i will try it later (it can, i already try it) :p
this is just for more clear explanation
cheers :p
Are your requests using either cookies or authorization by any chance?
Check on your ajax call on the client side if you're configuring it to be done "with credentials"
.withCredentials = true;
If yes, the wildcard(*) will not work and you'll need to provide the exact host as the value for Access-Control-Allow-Origin.
Refer to this stack overflow answer or Mozilla Documentation on CORS

Apache 2.2 "Script PUT /put.php" Ignoring Some Requests

I have Apache 2.2 set up to accept PUTs and funnel them to a specific handler script /put.php as shown below in the Directory Directive in httpd.conf:
<Directory />
Options FollowSymLinks
AllowOverride All
Script PUT put.php
</Directory>
This has always worked, no matter the request as long as the method is PUT in the past. I used curl to validate this using a request URL of "/" which pointed to index.html.
I recently found a need to convert index.html to index.php to do some session handling, and suddenly my PUT requests stopped being handled by /put.php as soon as the file became index.php.
I realize that one solution is to point all PUT requests to /put.php, but we have an app that is hard coded to send them to / which doesn't work anymore since the change to index.php.
It'd be nice to be able to get index.php to still send PUT requests to it to /put.php, but I haven't been able to find a way.
The apache logs show that the PUT requests are being handled properly (201 response and no error), but the behavior is just that it never redirects to /put.php as it used to.
I also tried leaving the page as html, and adding the following line to the httpd.conf prior to the "Script PUT /put.php" directive:
AddType application/x-httpd-php .html
which then parsed the html page with the php parser, but then I got the same effect (No redirection to put.php) as when the page was called index.php and parsed by php.
Anyone have any ideas or encountered this before? It is as if when I turn index.html into index.php and send to the php parser it is unable to redirect any longer using the "Script PUT" directive.

ERR_INCOMPLETE_CHUNKED_ENCODING Chrome Root page load

I have a website on a lamp stack with little to no extra configuration other than FallbackResource /index.php present in my root .htaccess
When I load the root page (localhost ) in Chrome I receive
GET http://192.168.163.171/ net::ERR_INCOMPLETE_CHUNKED_ENCODING VM110:1
in the chrome console after about 10 seconds. If I attempt to follow the link at VM110:1 it takes me to the top of my inline Javascript.
More information / What I've tried
This does NOT occur on any other page but root
There are no 404's in the access log nor any other abnormal codes
There are no errors appearing in the apache error log.
The error does not occur in the latest version of IE or Firefox.
It caused a problem in both my local environment and hosted. The latter has absolutely no config changes and I expect to be a near default install.
When I remove the FallbackResource directive my page loads fine without the error
In index.php the root is treated no different than any other page.
This would all be a non-issue because everything loads properly BUT it prevents javascript relying on a finished page load from working.
Any further ideas on what is causing the problem or new things I can try? I've considered moving to just using mod_rewrite but this is much simpler.
Finally found the answer while working on another site:
Before FallbackResource directive be sure to add a DirectoryIndex directive with the same file. Haven't had time to research why but it fixed my issue. I blame it on a Chrome bug or possibly Chrome being super picky because no other major browser has an issue.
I fixed this error by removing the following lines from my php5filter.conf file in the Apache configuration:
<FilesMatch ".+\.ph(p3?|tml)$">
SetInputFilter PHP
SetOutputFilter PHP
</FilesMatch>
To add to Blaine's answer (as I can't yet comment):
I believe this is an Apache configuration issue, not specific to Chrome.
I recently experienced this issue, and noted the following effects in various clients, again only with the home page:
Chrome, as stated, displayed the ERR_INCOMPLETE_CHUNKED_ENCODING error, but also didn't display the page correctly. The page continued to "load" for another 5 seconds even after all the content was visible.
A simple CURL request outputted the error curl: (18) transfer closed with outstanding read data remaining. The full HTML appeared, followed by the error after a delay.
Firefox and IE initially displayed the page incorrectly, as with Chrome, and again had the ~5 second additional loading time. However, after this period, the page suddenly reformatted itself correctly. No errors were seen in the respective developer consoles.
The solution to set the DirectoryIndex to the same location as FallbackResource resolved this for all clients.
Edit: An alternative if using mod_rewrite is to use something like RewriteRule ^$ index.php which will avoid affecting all subdirectories.
I don't know whether this is expected behaviour of Apache or a bug.
In my json response '\n' causing the issue. So after removing it, issue has been solved.

Categories