Why don't webroot/.htaccess rules do apply to themes? - apache

I added the following to the 'app/webroot/.htaccess' file to enable a far future expires header for resource files such as .css and .js. While this works fine for any content served out of the /js /css /img folders, it will not apply to anything placed in a CakePHP theme webroot/js|css|img folder.
Is there a similar method that should be used to control resource caching from themes? All of my theme resource files expire the next day as if its grabbing some sort of default.
There are no other Apache rules in place for mod_expires as I'm trying to keep it all in .htaccess.
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType text/css "access plus 1 week"
# ... Also added png,js etc...
</IfModule>

With the default settings of CakePHP, themed (and plugin-) assets are served via PHP, not directly handled by Apache. I'm not 100% sure, but this probably causes the htaccess settings not to be applied, because Apache does not see those files as 'static' files.
For a production site, it is advisable to change the settings, as is described here Increasing performance of plugin and theme assets
Additional tips on performance
As a side-note, for additional performance;
Have a look at the Server configuration files of Html5 Boilerplate. They are very well documented and offer a lot of valuable settings to speed up the performance of your website. A lot of research has been put into those settings, so that you dont have to do that yourself. Many of those settings also apply to CakePHP websites. You can find the configuration files here: https://github.com/h5bp/server-configs/tree/master/apache
Don't use .htaccess files, but move all rules/settings of your .htaccess files to your VirtualHost configuration and disable override. This way, Apache doesn't have to scan every directory for possible .htaccess files for each request

Related

Apache Server not serving SVGs

What settings do I need to set in order to make Apache serve SVGs?
What I found:
These questions document the use of .htaccess to serve the SVGs with the correct MIME type "image/svg+xml" SVG images not displaying on certain web servers / https://mid.as/kb/00134/configuring-server-to-handle-svg-images / https://davidwalsh.name/serve-svg-image
This question handles the Requested URL not found
None of these helped resolve this issue.
Files:
.htaccess:
AllowOverride All
RewriteEngine on
AddType image/svg+xml svg
Folder structure:
Result:
Other:
Different files like .png work. I also tested it with Node (npx http-server) which worked.
AFAICR any recent version of Apache should have the SVG MIME type already configured. You shouldn't have to do it yourself unless you are running a very old version.
Anyway, a misconfigured MIME type wouldn't casue a 404. I think something else must be going on.
If you haven't already, try looking at the Network tab in your browser dev tools, and the Apache access log to check whether you are actually fetching the URL you think you are. And check that the file permissions are set correctly. Does the file have the correct owner, group, and permissions to be accessed by apache?

Can a .htaccess file be hacked?

On a subdomain I want to use only a .htaccess file for redirects. No PHP, no database or something else will be used. Can a .htaccess file still be hacked? What should I do to protect it?
The apache2.conf file has following lines by default which prevent viewing of htaccess files:
#
# The following lines prevent .htaccess and .htpasswd files from being
# viewed by Web clients.
#
<FilesMatch "^\.ht">
Require all denied
</FilesMatch>
It will not be visible under standard Apache setup which blocks all files starting with.ht from being served. So nobody will be able to view the contents or get at it through the Apache front-end. Take the usual precaution of having it be 644 permissions and not owned by the user that Apache runs as. No extra security needed outside of protecting your server generally.
Check that the standard protection is in place, so it can't be viewed. Easiest way is just to try visiting it in a web browser. You should get a 403 forbidden.
If you're worried you could put the rules in the main server config instead. I wouldn't worry as long as the above is in place.

Control Cache Expiration For Custom File On Server

We have files that we serve to a Native Windows OS applications from our server. The files can change every minute so we need to ensure the user is downloading the latest file.
We've found that users on Portable WiFi's tend to get served an older file. So we are changing our servers .htaccess file expirations for certain files.
We serve a custom file type (.ebc) and the files contents are sent over HTTP as plain text. In this case should we use ExpiresByType text/ebc "access 1 minute"?
Will changing .htaccess cache control affect Portable Wifi caching or will this only affect browsers?
Should mod_expires / mode_headers occur code occur before redirects and rewrites? I've discovered before that you should perform certain .htaccess code operations before others (such as place redirects at the top of the file).
Heres my code:
RedirectMatch (?i)^/wp-content/uploads/2014/10/a.exe http://www.website.com/wp-content/uploads/2014/10/b.exe
## EXPIRES CACHING Should we place this before mode_rewrite or after? ##
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType text/ebc "access 1 minute"
</IfModule>
## EXPIRES CACHING ##
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
There are 3 questions here, so I'll attempt to answer them.
We serve a custom file type (.ebc) and the files contents are sent over HTTP as plain text. In this case should we use ExpiresByType text/ebc access 1 minute
That should be fine, as long as you have the text/ebc mime-type properly set on your server.
Will changing .htaccess cache control affect Portable Wifi caching or will this only affect browsers
I don't really know what "Portable Wifi caching" is. These headers are targeted at browsers only. If a custom application is downloading these files, it could be implementing its own caching and so these headers might get ignored.
Should mod_expires / mod_headers code occur before redirects and rewrites?
I'd put it before the redirects but only from a logical point of view. These are not like RewriteRules and think they get evaluated separately.
Additionally, I'll add that caching is difficult and once a file has left your server it can be hard to force an update. Different browsers behave different ways and I've come across configurations that work one place and not another.
I would additionally consider two other approaches to what you're attempting.
Firstly, don't cache your files at all:
<FilesMatch "\.ebc$">
Header set Cache-Control no-cache
Header set pragma no-cache
</FilesMatch>
Secondly think about implementing a cache-busting mechanism. If the file is linked from somewhere, try and make sure that link is changed (normally a querystring with a timestamp suffices) each time the file changes. You obviously then need to make sure whatever contains the link also isn't being cached.
An easier solution I used in the past was adding a parameter to the downloadable files.
For example, if the file you're serving is
http://www.domain.tld/file.pdf
then you can create the following link:
http://www.domain.tld/file.pdf?d486dFyg
The question mark and whatever comes after it (random) will be ignored but it will guarantee that the user will always download the latest version, as the URL will be different (because of the random always being different of course).
The downloaded file on the user's computer will just be file.pdf so absolutely no downside.
EDIT: I noticed some reference to WordPress in your question, which is PHP, so you can use the rand() function to append the random part: http://php.net/manual/en/function.rand.php

Enabling CORS .htaccess restrictions

I am encountering some behaviour from a produciton server and I was wondering if someone could confirm if something is possible and how it might have been done.
I have a website www.example.com with SSL enabled and all traffic forwarding to https
On that site I have a font file https://www.example.com/wp-content/assets/fonts/icons.ttf
I have additional campaign sites (e.g www.examplecampaign.com) that use the css file from example.com which loads in a font face using that font file. I am actually adding all the relevant file types woff, etc but will refer to ttf for simplicity. The icon font displays fine on www.example.com but on www.examplecampaign.com because in Firefox I get the error
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://www.example.com/wp-content/assets/fonts/icons.ttf. This can be fixed by moving the resource to the same domain or enabling CORS.
So here begins my problem. On our stage server which we have full access to I can add
# BEGIN REQUIRED FOR WEBFONTS
AddType font/ttf .ttf
AddType font/eot .eot
AddType font/otf .otf
AddType font/woff .woff
<FilesMatch "\.(ttf|otf|eot|woff)$">
<IfModule mod_headers.c>
Header set Access-Control-Allow-Origin "*"
</IfModule>
# END REQUIRED FOR WEBFONTS
to the .htaccess file and that solves the problem. However on our produciton server which is owned and managed by the client this header modification is ignored. I am using http://web-sniffer.net/ to test this.
To further complicate things I hvae found that if I just added
<IfModule mod_headers.c>
Header set Access-Control-Allow-Origin "*"
</IfModule>
on my stage site the header would appear when requesting any page or resource BUT on the production server if I added that the Access-Control-Allow-Origin would appear on all pages apart from the font files (and possible other resources).
So my question is, is it possible in Apache to disable / ignore header modification for a certain file type(s) and how would that be done. It's weird that it's so specific. We no longer have sudo access and have to request changes to conf files which is one of the reasons im making this change in .htaccess not that I think that would matter where this is set? Also example.com is a wordpress site but I don't think that would affect anything? As it's working on stage but not produciton.
Does anyone know of the Apache configuration that would restrict the use of mod_header in that way?

What is .htaccess file?

I am a beginner to Zend framework and I want to know more about the .htaccess file and its uses. Can somebody help me?
I found an example like this:
.htacess file
AuthName "Member's Area Name"
AuthUserFile /path/to/password/file/.htpasswd
AuthType Basic
require valid-user
ErrorDocument 401 /error_pages/401.html
AddHandler server-parsed .html
It's not part of PHP; it's part of Apache.
http://httpd.apache.org/docs/2.2/howto/htaccess.html
.htaccess files provide a way to make configuration changes on a per-directory basis.
Essentially, it allows you to take directives that would normally be put in Apache's main configuration files, and put them in a directory-specific configuration file instead. They're mostly used in cases where you don't have access to the main configuration files (e.g. a shared host).
.htaccess is a configuration file for use on web servers running the
Apache Web Server software.
When a .htaccess file is placed in a directory which is in turn 'loaded via the Apache Web Server', then the .htaccess file is detected and executed by the Apache Web Server software.
These .htaccess files can be used to alter the configuration of the Apache Web Server software to enable/disable additional functionality and features that the Apache Web Server software has to offer.
These facilities include basic redirect functionality, for instance if a 404 file not found error occurs, or for more advanced functions such as content password protection or image hot link prevention.
Whenever any request is sent to the server it always passes through .htaccess file. There are some rules are defined to instruct the working.
Below are some usage of htaccess files in server:
1) AUTHORIZATION, AUTHENTICATION: .htaccess files are often used to specify the security restrictions for the particular directory, hence the filename "access". The .htaccess file is often accompanied by an .htpasswd file which stores valid usernames and their passwords.
2) CUSTOMIZED ERROR RESPONSES: Changing the page that is shown when a server-side error occurs, for example HTTP 404 Not Found.
Example : ErrorDocument 404 /notfound.html
3) REWRITING URLS: Servers often use .htaccess to rewrite "ugly" URLs to shorter and prettier ones.
4) CACHE CONTROL: .htaccess files allow a server to control User agent caching used by web browsers to reduce bandwidth usage, server load, and perceived lag.
More info : http://en.wikipedia.org/wiki/Htaccess
You are allow to use php_value to change php setting in .htaccess file. Same like how php.ini did.
Example:
php_value date.timezone Asia/Kuala_Lumpur
For other php setting, please read http://www.php.net/manual/en/ini.list.php
Htaccess is a configuration file of apache which is used to make changes in the configuration on a directory basis.
Htaccess file is used to do changes in functions and features of the apache server.
Htaccess is used to rewrite the URL.
It is used to make site address protected.
Also to restrict IP addresses so on particular IP address site will not be opened
You can think it like php.ini files sub files.. php.ini file stores most of the configuration about php like curl enable disable. Where .htaccess makes this setting only for perticular directory and php.ini file store settings for its server' all directory...
It is not so easy to give out specific addresses to people say for a conference or a specific project or product.
It could be more secure to prevent hacking such as SQL injection attacks etc.
.htaccess file create in directory /var/www/html/.htaccess
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^ index.php [QSA,L]
</IfModule>
What
A settings file for the server
Cannot be accessed by end-user
There is no need to reboot the server, changes work immediately
It might serve as a bridge between your code and server
We can do
URL rewriting
Custom error pages
Caching
Redirections
Blocking ip's