Problem with .htaccess and "everyone" group
|
Baldrick
Joined: 2009-10-27
Posts: 25 |
Posted: Tue, 2009-10-27 16:37
|
|
Hi there, I am trying to get Gallery 3 working. It looks great, but I’ve run into a bit of a snag. Installation completes successfully, and I can add an album. My plan to do that was to go to the root of the gallery, and deselect all “everyone” permissions there, and leaving all rights checked for “registered users”. What happens however is that as soon as this is done, a .htaccess file is dropped in the album folder, as well as the thumbnail and resize folder, which contains just this: <IfModule mod_rewrite.c> This results in registered users being able to see the album exists – but they are blocked from fetching thumbnail, resize, and full size image, resulting in a page with “crosses” wherever these should have been loaded. In fact, it is blocked for the Admin account as well. I searched a bit and I found this thread: http://gallery.menalto.com/node/91986 However, I have tried removing spaces from directory names, and the problem is the same. I think this person maybe has the same problem I do. Am I not understanding the approach to rights granting correctly, or is something else amiss? Thanks in advance for your help, and for developing this great software. Kind regards, Baldrick |
|
Posts: 16504
Change permissions back so Everybody has view permissions and post or PM me a link to your site.
This really sounds related to this:
https://sourceforge.net/apps/trac/gallery/ticket/812
____________________________________________
Like Gallery? Like the support? Donate now!!! See G2 live here
Posts: 25
I have sent you a PM with link to my site. Just reposting the rest of the reply here as well, in case it helps others.
I have created 2 test albums, one with spaces in the folder name, and one without. Both contain 1 picture, with no special characters or spaces.
Both are perfectly visible, thumbnail, resized version and full version all work. As soon as I remove access for "Everybody", the .htaccess file is dropped and neither folder can be seen anymore.
Given the fact that I used no spaces in the naming for one of the two and it still didn't work, I wonder if it's the exact same problem you described in the ticket posted above.
Is it possible there are not enough permissions somehow to later modify the dropped .htaccess file meaning authorized users are blocked as well?
Thanks
Posts: 16504
Well I was looking at it, but access was cutoff ;)
Please PM me a login.
____________________________________________
Like Gallery? Like the support? Donate now!!! See G2 live here
Posts: 25
Sent!
Thanks
Posts: 16504
o.k. I'm wondering something here and I never tested this before it was fixed.
Does any directory in the path to your gallery3 install have a space, ~ or '?
Also, since a bug was just fixed last night, try upgrading to the latest experimental version:
http://codex.gallery2.org/Gallery3:Upgrading
Make sure to go to gallery.example.com/index.php/upgrader and to follow the tips about unpacking the code.
____________________________________________
Like Gallery? Like the support? Donate now!!! See G2 live here
Posts: 25
Hi!
No, there are no spaces, tildes or apostrophes anywhere. Just an underscore in the public_html path.
It's like this:
/home/blabla/public_html/gallery and then just the installation below that.
I will do the upgrade right now and get back to you.
*update*
I ran the updater by going to the automatic updater page, it took the core from 14 to version 15. I take it there is no newer code to somehow apply?
Unfortunately the problem remains.
Thanks
Posts: 27300
We are at core version 16.
Dave
_____________________________________________
Blog & G2 || floridave - Gallery Team
Posts: 16504
Check your var/logs directory (under your G3 directory) and see if there are any error logs in there.
____________________________________________
Like Gallery? Like the support? Donate now!!! See G2 live here
Posts: 16504
Didn't see Dave's post before
Yeah, 15 ain't right. The fix I was referring to above was done last night and the core was bumped to version 16 yesterday morning or the day before.
____________________________________________
Like Gallery? Like the support? Donate now!!! See G2 live here
Posts: 25
Hi,
I replaced the code and am now at core 16 and users/groups 2. The problem remains.
Only info from my logfile from today:
?php defined('SYSPATH') or die('No direct script access.'); ?>
2009-10-28 08:03:41 -06:00 --- error: <pre>(array) Array
(
[language] => SafeString Object
(
[_raw_string:private] => Language Preference
[_is_safe_html:protected] => 1
)
)
</pre>
Thanks
Posts: 16504
Any way you could give me SSH or FTP access?
____________________________________________
Like Gallery? Like the support? Donate now!!! See G2 live here
Posts: 25
Sending you the details now. Can't do SSH but FTP should work.
Posts: 16504
Can you find out what version of Apache is running on the server?
____________________________________________
Like Gallery? Like the support? Donate now!!! See G2 live here
Posts: 25
Apache version 2.2.13 (Unix)
PHP version 5.2.9
Posts: 25
Hi,
Anything else you need me to check?
I'd love to get started, the rights issue is the only thing preventing me from implementing Gallery3 at the moment.
Kind regards,
B.
Posts: 16504
Could you post a link to phpinfo?
I'd like to get a dev to look at this. For some reason your server works with URL Rewrites, but it doesn't like these rewrite rules. Can I send the login info you've sent me to one of the developers? Do you have access to the error logs for your site? If so, please look at those and see if there are any entries in there.
____________________________________________
Like Gallery? Like the support? Donate now!!! See G2 live here
Posts: 25
Hi,
Sure, feel free to pass on the logon info. I will send you the link to phpinfo in a PM as well.
As for error logs - I checked several (including the php error log) but there are no recent entries in there.
Anything else I can do to help, let me know.
Posts: 16504
Have you checked the Apache error and access logs?
____________________________________________
Like Gallery? Like the support? Donate now!!! See G2 live here
Posts: 25
Whoa, looks like the logs had just been cleaned out when I last checked, it has built up a new list now:
[Mon Nov 02 09:38:38 2009] [warn] RewriteCond: NoCase option for non-regex pattern '-f' is not supported and will be ignored. [Mon Nov 02 09:38:39 2009] [warn] RewriteCond: NoCase option for non-regex pattern '-f' is not supported and will be ignored. [Mon Nov 02 09:38:39 2009] [warn] RewriteCond: NoCase option for non-regex pattern '-f' is not supported and will be ignored. [Mon Nov 02 09:38:39 2009] [warn] RewriteCond: NoCase option for non-regex pattern '-f' is not supported and will be ignored.
I also got one of these with a specific client address in front of it, don't know if it's related:
Request exceeded the limit of 10 internal redirects due to probable configuration error. Use 'LimitInternalRecursion' to increase the limit if necessary. Use 'LogLevel debug' to get a backtrace.
Does that tell you anything?
Cheers
Posts: 25
Hmm, I just realized one thing - The server has a PHP FastCGI option that is used by default to reduce overhead as it's a shared box. I just switched that off and reverted to normal PHP and it seems to be working!
I will test a bit more if everything works as intended now, with a new album, and let you know.
Posts: 25
It looks like it is ok. The only thing I noticed is that when I add pictures and block "Everyone" access at the top gallery level, the newly added album folder, thumbnail folder, and resize folder don't automatically get a .htaccess file dropped in them, so they can be opened by anyone who knows the path.
If I then explicitly deny permission again on the album itself, the .htaccess file is dropped and it works correctly.
Is this something I can change in the settings?
Thanks for all the help!
Posts: 16504
That last behavior you're mentioning shouldn't be that way. I'll have to look into that and see if I can reproduce on my install.
As for the other info about fastcgi and url rewrite not working right on your install. That's good info to check on. I did some searching and it looks like they are suppose to behave correctly, but others had problems with other stuff (not gallery) too.
____________________________________________
Like Gallery? Like the support? Donate now!!! See G2 live here
Posts: 25
Thanks again for all your help, I really appreciate it.
I have one more question, unrelated to the previous.
Some of the items I am uploading are movies. I know only FLV and MP4 are supported for the moment, but the problem is my shared hosting environment does not support FFMPEG.
I don't necessarily need to have these movie clips display within the gallery itself, it would be good enough if the item was visible as an icon that, upon clicking, would allow you to download the item for offline viewing. I had this approach in version 2 as well.
Is there any way to accomplish this in Gallery3?
Thanks
Posts: 16504
I have no idea. I don't have any flv or mp4 movies to test with. I think ffmpeg is only used to grab a frame to display as a thumbnail anyway.
I searched for bugs and only found this:
http://sourceforge.net/apps/trac/gallery/ticket/564
Which makes it sound like there is already a default icon for movies if ffmpeg can't create a thumbnail.
If you can post or pm me a link to an flv I can try it on my test server.
____________________________________________
Like Gallery? Like the support? Donate now!!! See G2 live here
Posts: 25
I don't actually have an flv or MP4 yet, but I have some AVI and other files that I would like to have in there. It could be on a default icon that's clickable to initiate download.
What's happening now is that if I add a folder with JPG and AVI in it, the AVI is automatically ignored in the server add process.
This prohibits me from putting them in there.
Is there any way around that?
Thank you!
Posts: 16504
Nope, G3 ignores files it doesn't support. You'll need to convert them.
There's been some work on this, but for now you'll need to convert, you might be able to use the stuff rWatcher posted here:
http://gallery.menalto.com/node/91394
____________________________________________
Like Gallery? Like the support? Donate now!!! See G2 live here
Posts: 1
Just as a note I am having the same exact issues. As soon as i remove "Everyone" from the permissions, I can no longer view thumbs. It definitely has something to do with the rewrite rules.
Posts: 25
Hi Demogorgon,
It was fixed for me after I
1) uploaded the latest experimental code
2) changed FastCGI to regular PHP handling on the server
3) removed and re-applied rights so .htaccess was removed and inserted again
Maybe that works for you as well?
Posts: 13
I can confirm that I had the same issue with Gallery3 Beta 3. Disabling FastCGI on my shared server fixed the problem.
Posts: 13
I fixed the problem with my installation.
The problem, I believe, is with the .htaccess file being created. I changed the .htaccess file in albums, thumbs, and resizes to the following:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^/(.*) /gallery3/index.php/file_proxy/$1 [L]
</IfModule>
<IfModule !mod_rewrite.c>
Order Deny,Allow
Deny from All
</IfModule>
My installation (GIT HEAD) now works with FastCGI. The change is the "RewriteRule" line. I changed it from:
RewriteRule (.*) /gallery3/index.php/file_proxy/$1 [L]
to:
RewriteRule ^/(.*) /gallery3/index.php/file_proxy/$1 [L]
No real idea what the extra ^/ does, but it seems to have helped. I am on Dreamhost, and they seem to cause a lot of problems with .htaccess mod_rewrite rules, which seems to be related to the way the environment is configured for FastCGI.
Posts: 7994
Wacky. I would expect (.*) to match everything. The only thing I can think of is that internally there's an extra slash that's throwing things off. One thing that would be useful to us.. revert your RewriteRule change back to the code we generate, and then go into modules/gallery/controllers/file_proxy.php and in the __call() function, change this code:
29 class File_Proxy_Controller extends Controller { 30 public function __call($function, $args) { 31 // request_uri: http://example.com/gallery3/var/trunk/albums/foo/bar.jpg 32 $request_uri = $this->input->server("REQUEST_URI"); 33 $request_uri = preg_replace("/\?.*/", "", $request_uri);to:
29 class File_Proxy_Controller extends Controller { 30 public function __call($function, $args) { 31 // request_uri: http://example.com/gallery3/var/trunk/albums/foo/bar.jpg 32 $request_uri = $this->input->server("REQUEST_URI"); 33 $request_uri = preg_replace("/\?.*/", "", $request_uri); 34 Kohana::log("error","request_uri: " . print_r($request_uri,1));Then when the error happens again, go into var/logs and look there to see what it's giving you for the request_uri.
---
Problems? Check gallery3/var/logs
bugs/feature req's | upgrade to the latest code | use git
Posts: 13
Well, this is embarrassing.... The only reason the 'fix' seemed to work is because the RewriteRule wasn't firing, allowing direct access to the file.
I have further diagnosed the problem that occurs with FastCGI enabled. When one attempts to access http://example.com/gallery3/var/thumbs/2009/me.jpg, the RewriteRule fires and makes the PHP process call http://example.com/gallery3/index.php/file_proxy/2009/me.jpg. PHP FastCGI then looks for /gallery3/index.php/file_proxy/2009/me.jpg, but because that is not a real file (it is supposed to call index.php), it throws a "No input file" error. For some reason, PHP as CGI (not FastCGI), correctly interprets the request as calling index.php, and the request runs correctly.
Posts: 13
I found something here: http://wiki.dreamhost.com/Mod_rewrite
So, placing a '?' after index.php indeed makes index.php be called, but now there is a "disallowed key characters in global data" (From system/libraries/Input.php). Commenting this out just to allow the process to proceed (line 406), now correctly fires file_proxy, but the request does not complete correctly, because the REQUEST_URI is not set correctly when the '?' is added.
Posts: 13
I believe I have solved it, finally. Using this page: http://dev.kohanaphp.com/issues/1923
Changed
RewriteRule (.*) /gallery3/index.php/file_proxy/$1 [L]
To
RewriteRule (.*) /gallery3/index.php?kohana_uri=/file_proxy/$1 [L]
Tested under CGI and FastCGI. I am able to access my thumbs,albums, and resizes when logged in, but an error page is displayed when not logged in. No other modifications are required.
Posts: 16504
That would probably be this bug:
http://sourceforge.net/apps/trac/gallery/ticket/922
____________________________________________
Like Gallery? Like the support? Donate now!!! See G2 live here
Posts: 7994
I think that this is unrelated to ticket #922 because it's gating an individual image access, not the whole page. I filed a separate ticket:
https://sourceforge.net/apps/trac/gallery/ticket/928
And have implemented the fix that lsowen suggested. Try the latest code and see if it fixes your problem. Note that you'll have to grant, then remove permissions to have it update the .htaccess files!
---
Problems? Check gallery3/var/logs
bugs/feature req's | upgrade to the latest code | use git
Posts: 2
I have exactly the same problem with thumbnails not being displayed.
FastCGI is enabled on my server.
Codebase 19 did NOT fix this problem.
edit: .htaccess says:
vi .htaccess
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule (.*) /pics/index.php/?kohana_uri=/file_proxy/$1 [L]
</IfModule>
<IfModule !mod_rewrite.c>
Order Deny,Allow
Deny from All
</IfModule>
This means it has been updated...
Also i observe significant higher loading times if thumbnails are not displayed (no changes if no restrictions applied)
Posts: 13
Codebase 19 has an extra slash between index.php and the question mark. Remove this slash (so the line becomes index.php?kohana_uri instead of index.php/?kohana_uri), and everything will begin displaying correctly.
Posts: 2
i can confirm this fix is working.. looking forward to codebase 20 ;-)
Posts: 7994
I pushed a change earlier today that gets rid of the extra slash. Please let me know if that fixes it.. thanks!
---
Problems? Check gallery3/var/logs
bugs/feature req's | upgrade to the latest code | use git
Posts: 13
bharat:
Looks like it fixes the issue. Now works great under FastCGI.
As an aside, your next commit (http://github.com/gallery/gallery3/commit/852653ef2415dc070c27ce151ed399525ddfa5a0), looks like it broke something, at least for me. Now I can't get to the "top level" gallery (the root gallery?), even when logged in.
It gives me the following:
Posts: 7994
@lsowen -- doh! a typo on my part.. fixed. Sorry about that!
---
Problems? Check gallery3/var/logs
bugs/feature req's | upgrade to the latest code | use git