Disappearing images - file_proxy / permissions issue

[nivekiam]

Steps to reproduce:
Edit permissions on an album to remove Everybody

Edit the filename of a photo/movie/album so it doesn't match the internet address.

Filename: Cool Picture.jpg
Internet Address: Cool-Picture

Equals broken picture. However, if you allow Everybody to view it, then it's not going through the file_proxy and things just work.

This doesn't appear to be case sensitive, but with us not allowing spaces, &, and other chars in URLs which are legal in file and directory names it's creating quite a mess:
http://gallery.menalto.com/node/90978#comment-322294

Forum references:
http://gallery.menalto.com/node/90854
http://gallery.menalto.com/node/91413
http://gallery.menalto.com/node/91427

NOTE: it doesn't appear that the references I make to editing the .htaccess in some of those forum threads to enable the rewrite rules actually have an effect here. That might have been a fringe case where that worked for me in helping a user.

[tnalmdal]

I just tried this and it worked fine for me in my branch. Is it still an issue.

[nivekiam]

Happens for me if the file or directory (for an album) name has a space in it.

[nivekiam]

appears to be working now. Thanks tnalmdal. Closing ticket.

[nivekiam]

Browser cache and bouncing around between different web servers... (This is all on Apache though)

It's still broken for me. Here are the steps I'm going through:

1) Edit a photo (or an album)

2) Ignore the title, edit the Filename and make it img 2395.jpg

3) Set the internet address to anything you like

4) Remove the View and View Full Size permissions from the album

5) In Firefox, press Ctrl+Shift+R to reload the page

This happens with either a space, ~ or ' in the filename.

I noticed in modules/gallery/controllers/file_proxy.php it's looking at the path of the file and seeing something like img 2953.jpg, then tries to look that up in relative_path_cache where it's listed as img%202953.jpg and not finding a match.

In file_proxy.php, if I change $path like so (only using a space in the filename as an example here):

$path = str_replace(array(" "), array("%20"), $path);

before it does that look-up it appears to work

[tnalmdal]

Don't url encode the components of the relative_path_cache as we they refer to file paths and they are converted back in the file proxy.

http://bit.ly/4rS7Kl

[bharat]

This is the wrong fix. We need to leave those path components urlencoded because we use the relative_path in browser contexts. urlencoding them in the database is much more efficient, but it means that if you want to consider this in a file context you need to decode it.

Here's the API Doc for Item::relative_path():

/**

• Return the relative path to this item's file. Note that the components of the path are
• urlencoded so if you want to use this as a filesystem path, you need to call urldecode
• on it.
• @return string */

I think the right fix is to call urldecode on the relative_path_cache() in file_proxy.php.

[tnalmdal]

Refix #812, by removing the decoding in file_proxy instead of not encoding in Item_Model when creating the relative_path_cache.

http://bit.ly/1IgS9p