I am having a problem loading a javascript or css or any other file from inside the application/modules directory.
I am using MAMP and CodeIgniter with HMVC and trying to have a js and css folders inside a module folder. Then when I am calling the controller methods I am also loading the asset files.
I have other sites that are working in that way. The structures are the same and the CodeIgniter versions are the same. Basically I have copied the previous website and started from there.
But it always returns 403 forbidden.
What I did but still nothing changes:
the whole site directory is writable and readable.
I can create and read new files from PHP to that dir
I have htaccess file which I tried to remove or change
Reinstalled MAMP
Tried to open a simple html file
The MAMP user and group has full access to the dir
I tried to run the website on another server
The apache log says "[Tue May 22 17:24:30 2012] [error] [client 127.0.0.1] client denied by server configuration"
Here is the .htaccess file:
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php/$1 [L]
At the same time everything is fine with the other site.
I have spent many hours so far and I am stuck.
Any thoughts or suggestions are appreciated.
Thanks,
CodeIgniter comes with a .htaccess in the /application directory which contains
Deny from all
You'll need to remove this file or change it's ruleset to access js/css files etc from anywhere inside application/*
It is however largely inadvisable to allow access entirely to the application, it's perhaps best to modify this .htaccess file to allow access to application/modules/*/css|js/
Related
I'm trying the second way to run PHP code in HTMl file using a rule in .htaccess file as described by the link https://stackoverflow.com/a/6237056/3208225
RewriteEngine on
RewriteRule ^(.*)\.html $1\.php
But when I try opening my page e.g. test.html I receive
Not Found
The requested URL /test.html was not found on this server.
Why and how to resolve?
UPDATED (from comments)
I try both on localhost and on my shared hosting. htaccess and html files are in document root. BTW, the homepage (index.html) also returns Not found. In local machine the path is D:/Server/vhosts/another. And without this htaccess such virtual host works just fine. So there is no issue with its configuration.
With your shown samples please try following .htaccess rules file. Make sure your htaccess is present along with your php files only. Also clear your browser cache before testing your URLs.
RewriteEngine ON
RewriteRule ^(.*)\.html/?$ $1.php [NC,L]
Fix added by OP: Please note such rule is not execution of PHP code inside of HTML file, but just a redirecting from HTML file to PHP file, so the second file also must exist
I need to create a rewrite to take traffic going to mp3/mp4 files in a specific subdirectory and then route them to a PHP file that tracks download stats etc before routing them to the actual file location since iTunes requires your podcast RSS contain actual media file extensions (.mp3, .mp4, etc)
I have created rewrites before with no problem but now I am running into an odd issue on this company's server.
My .htaccess located at www.company.com/companytools/podcasts
RewriteEngine on
RewriteRule ^/(.*).mp3$ /test.php?file=$1 [r=301,L]
Right now it is partially working it does act upon the mp3 file but ends up including the full path to test.php after the domain, so I end up with a 404 page looking for this URL:
www.company.com/www/internal/docs/companytools/podcasts/test.php?file=test
basically I need the path, but only the /companytools/podcasts part.
Any help is appreciated.
You may not need R=301 here to hide actual PHP handler.
Try this rule with RewriteBase:
RewriteEngine on
RewriteBase /companytools/podcasts/
RewriteRule ^(.+?)\.mp3$ test.php?file=$1 [L,QSA]
I'm using WAMP Server, mostly configured as-is out of the box. I'm having trouble getting mod_rewrite to behave as expected locally (everything works fine on a production server).
I have a PHP file located at:
/ajax/graphs/get-graph.php
The way this file is normally invoked is via a bootstrap file loaded by
/index.php
I have a .htaccess file at the root with the following rules:
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ /index.php [L]
So, basically, when my app requests via AJAX a call to /ajax/graphs/get-graph/it should be directed to /index.php.
The problem is, Apache/mod_rewrite sees the request path and loads /ajax/graphs/get-graph.php directly.
How do I prevent Apache from assuming that /ajax/graphs/get-graph/ is a valid file because a php file of the same name exists at that location?
It sounds like you've fallen into the trap of content negotiation ;-) As explained in the Apache documentation, there is an option called MultiViews which, when enabled, causes Apache to basically convert nonexistent directory names into their corresponding filenames.
The effect of MultiViews is as follows: if the server receives a request for /some/dir/foo, if /some/dir has MultiViews enabled, and /some/dir/foo does not exist, then the server reads the directory looking for files named foo.*, and effectively fakes up a type map which names all those files...
The intent is that you can have several versions of a file in different formats or languages, like
/some/dir
- foo.en.gif
- foo.en.png
- foo.en.jpg
- foo.fr.gif
- foo.fr.png
- foo.fr.jpg
and Apache will choose the best one based on the preferences provided by the browser.
To fix it, all you should need to do is add the directive
Options -MultiViews
in a <Directory> or <Location> block corresponding to /ajax/graphs. Or, if you don't have access to the main server configuration, you can put it in /ajax/graphs/.htaccess.
I have a directory with a bunch of files in it & I don't want anybody to be able to access these files by either getting a directory listing or by guessing the file location & typing it in.... it should NOT allow them to download it.
I accomplished this by putting the below in my .htaccess file:
Options -Indexes
Order Allow,Deny
Deny from all
However, I want the user to be able to download the file ONLY IF they access it via a script (which is in a different directory) which will give them the download. At the moment with the above settings it doesn't work.
I thought of putting something like..
Allow from domain.com
But I'm not 100% sure what that means? Does that check where the REQUEST is coming from & hence it would work if the server requests access to that dir? ...or would it still not work as the user is still using the domain via the other script to access the dir?
If you dump the files with an "script" you can store your files outside the documentroot. So you need no htacces file.
Perhaps this is a better workaround.
One way is to redirect the user say to your home page when they try to access your downloadable files inside the folder sec_files in this example.
I researched on this when one of my clients who purchased secure download links a codecanyon product asked for a solution to protect a folder that contained images or downloadable.
the .htaccess code is below. this .htaccess file is placed inside the sec_files i.e downloadable files folder.
RewriteEngine on
RewriteCond %{REQUEST_URI} ^/~sec_files/ [OR]
RewriteCond %{HTTP_HOST} ^www.satyamtechnologies.net$
RewriteRule ^(.*)$ http://www.satyamtechnologies.net [R,L]
See how it works when you access here, it will redirect you to home page but when you access it through a php script here it will let you download the same files.
Ok, so this problem recently arose and I don't know why it is happening; it's actually two problems in one...
0. My .htaccess file, for reference. (EDITED)
Options -Indexes +FollowSymLinks
RewriteEngine On
RewriteBase /
ErrorDocument 400 /index.php?400
ErrorDocument 401 /index.php?401
ErrorDocument 403 /index.php?403
ErrorDocument 404 /index.php?404
ErrorDocument 410 /index.php?410
ErrorDocument 414 /index.php?414
ErrorDocument 500 /global/500.php
RewriteCond %{HTTP_HOST} !^$ [NC]
RewriteRule .* index.php [L]
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^https?://(.*\.)?(animuson)\.(biz|com|info|me|net|org|us|ws)/.*$ [NC]
RewriteRule ^.*$ - [F]
1. My 'pictures' folder is following the hard path instead of the redirect.
I have no idea WHY it is doing this. It's really bugging me. The 'pictures' folder is a symbolic link to another place so that I can easily upload files to that folder without having to search through folders and such via my FTP account, but that's the only thing I use it for. However, when I visit http://example.com/pictures my htaccess sees it as accessing that other folder, which is restricted, and throws a 403 error rather than redirecting to index.php and displaying the page like normal.
I figured it has something to do with that specific folder being a symbolic link causing it to act oddly, but I have determined that my rules are not being applied to folders at all. If I visit folders such as 'css' and 'com' which are folders in the web root, it displays a 404 error page and adds the '/' to the end of the URL because it's treating it as a directory. It also does the same 403 error for my 'images' directory which is set up in the same fashion.
So, the question here is how do I modify my RewriteRule to apply to the directories as well? I want everything accessed via the web to be redirected back to index.php while maintaining the full access path in the address bar, why is it not working? (I'm pretty sure it was working fine before.)
Here's a small chart to show the paths they're following...
example.com/pictures -> pictures/ -> /home/animuson/animuson-pictures -> 403
example.com/com -> com/ -> 404
example.com/test -> index.php
example.com/ -> index.php
example.com/images -> images/ -> /home/animuson/animuson-images -> 403
example.com/css -> css/ -> 404
EDIT: Following information added.
Apache is processing the structure of the directory first. It's determining if the path exists based on what was typed into the address bar. If someone types in a folder name that happens to exist, it will redirect the user to the path with the "/" at the end of the URL signifying that it's a directory. For the 'pictures' directory explained above, the user does not have permission to access that folder so it is redirecting them to a 403 Access Denied page rather than simply showing the page that is supposed to be displayed there via the RewriteRule above. My biggest question is why is Apache processing the directory first and how do I make it stop doing that? I would really love an answer to this question.
2. Why is my compression not working? (EDIT: This part is fixed.)
When analyzing my site through a web optimizer, it keeps saying my page isn't using web compression, but I'm almost 100% positive that it was working fine before under the same settings. Can anyone suggest any reasons why it might not be working with this set up or suggest a better way of doing it?
Where is this .htaccess file situated? At the root or in the pictures directory?
1) You're using Options -Indexes which will deny access to directory listings. This is handled by /index.php?403 which in turn will redirect to /403. (I confirmed this by manually going to /index.php?403) I don't see any other rules in the posted .htaccess that are supposed to affect this. So this either happens because either index.php or some other .htaccess file or server rule makes that redirect.
You might also want to check the UNIX file permissions of the directory in question.
2) According to this aptimizer, http://www.websiteoptimization.com/services/analyze/, compression is indeed enabled for html, js and css files, as specified in the rules. My bet is that the optimizer is being stupid and does one of these three things:
1)) Complaining about images not being compressed. (It's generally a bad idea to compress images because they're typically already compressed and the extra CPU load typically isn't worth it since the net gain is so small. So your rules are OK in this regard.)
2)) It might think that DEFLATE doesn't count as compression, and wants you to use GZip.
3)) It might also react to the externally included StatCounter js file, which is not compressed. (And there's not much you can do about that.)
After a while of deliberating on Apache's IRC channel, I was finally able to figure out the real reasoning behind this on a fluke. I just happened to be looking at the directory structure using ls -l and noticed that all of the symbolic links had somehow has their permissions changed to animuson:animuson from the root:root original. I tried to run a simple chown root:root on them and it had no effect, so I deleted them all and recreated them and the problem has gone away. I don't really have any idea why the permissions made any different in this scenario but the solution worked and everything is okay now. I've also added a DirectorySlash Off to my .htaccess file to get rid of the slashes after folders that exist, just to make it look all that much nicer.