Path Magic

[jscheuer1]

OK, so I'll go into all of the gory details if I must. But here's the concept:

I have two absolute paths - say:

1. http:/somedomain.com/gallery/

2. http:/somedomain.com/gallery/images/

Now, just about anyone knows that if I'm in the second one, the first one is:

../

and:

http:/somedomain.com/gallery/images/../

But I could be anywhere. If I know the absolute path of where I am (#2 in the example), and the absolute path of where I want to reference (#1 in the example), is there a PHP function (or can one be created) that will give me ../, or whatever it might be (given the possibility that #1 and #2 might be reversed or entirely different, but will always be on the same domain)?

In other words, can we do something like so:

function findRelativePath($absPathOne, $absPathTwo){
    // work some magic here
    return relativePath from $absPathTwo to $absPathOne;
} 

[traq]

There's a function called realpath() that does the exact opposite. Look at the second user's example (posted by jpic) for a possible solution (I didn't try it out, though).

[jscheuer1]

There's a function called realpath() that does the exact opposite. Look at the second user's example (posted by jpic) for a possible solution (I didn't try it out, though).

Thanks, I stumbled upon that earlier today and have already implemented it. It works fine for my purposes. I had to add a trailing slash to the output though. I suppose that for some other purposes it could be fine 'as is', though I'm not sure what purposes those would be.

[traq]

just out of curiosity, why do you want to use relative paths when you know the absolute paths?

[jscheuer1]

I'm working on a fusion of PHP Photo Album:

http://www.dynamicdrive.com/dynamici...photoalbum.htm

and image moderation.

This somewhat idle task was inspired by this thread:

http://www.dynamicdrive.com/forums/s...ad.php?t=55981

where I believe I worked things out to the OP's satisfaction.

But it got me to thinking . . .

One of the requirements of the modifications in that thread is that one know the relative path back from the folder with the images in it to the folder with the page that views those images. It's either that or (I imagine) do a lot of rewriting of the ddphpalbum.js file, which I'm trying to keep intact as much as possible so that it can still be used on the same server for a conventional PHP Photo Album page. I suppose a more creative approach to the issue of how to display the desired 'deleted' image as a placeholder might also suffice.

I was thinking of copying it to the images folder as the filename that was deleted. That actually could work out well and cut down on a lot of code. But if the file type (.jpg, .png, etc.) doesn't agree with the deleted image, there will be other issues. And we begin to get a lot of files lying around that we really don't need. I could have one for each supported image type and do a cleanup routine, but this whole tack seems messy.

I''ve already added viewing the larger image before deciding on deletion, as well as a way to store the deleted image in a deleted folder (recycle bin).

Next are a ways to restore all, restore one, and to clean out the contents of the "recycle bin". These should all be fairly simple.

I would appreciate you having a look at my unlink.php:

<?php   
$file = isset($_GET['del'])? $_GET['del'] : false;   
if($file and file_exists($file)){   
    $file = basename($file, '.php'); // should limit deletion to the folder this page is in and skip the getalbumpics.php & this file - test!   
}   
$success = false;   
if($file and file_exists($file)){   
    @$success = unlink($file);   
}   
if($success){   
    echo $file . ' successfully deleted.';   
} else {   
    echo 'There was a problem deleting ' . $file;   
}   
?>

Do you think that the way I've used basename is sufficient to prevent the script from being used to delete other files outside the folder? Do you think it's vulnerable to any sort of injection via its query string that could make it do something bad?

[jscheuer1]

Oh, and it occurred to me that I didn't really answer your question.

The relative path is needed to get from the typical array entry for an image:

"someimage.jpg"

Which will only be looked for in what is known as the baseurl in the script, an absolute path to the images folder generated by the getalbumpics.php script.

If I know that path and the path where I want my placeholder to be (for many reasons it's good not to have it in the same folder as the images), I can "get there from here" by changing the image array entry to the placeholder filename preceded by the relative path from the images folder to wherever the placeholder image is.

The javascript will resolve it as something like:

http://www.somedomain.com/gallery/images/../placeholder.gif

If I use the absolute path though, the javascript will resolve it as something like:

http://www.somedomain.com/gallery/images/http://www.somedomain.com/gallery/placeholder.gif

[traq]

hmm... okay.

I haven't actually worked anything out on the php end, but it's interesting, and I'll try to do it later. It would look something like this:

<?php

$file = // filename from GET
$dir = // VALID image directory relative to site root to look for file in 
        // (setting this ourselves helps prevent hacking)
$file = basename($file);  // just the filename, no path info

// getimagesize will return FLASE if the file isn't an image
if(getimagesize($dir.$file)){
  // rename the file, or move it to a "recycle bin"
  // actually deleting things can be REAL bad
}

?>

I dunno. I'll work on it.

[jscheuer1]

This file is in the folder that it will act upon. Isn't making the filename reduced to its basename() enough to restrict it to the folder the script is in?

The only files that are in the folder are image files and .php files. By using the parameter '.php' with basename(), it will strip that extension. So when the the script 'asks' for the second time:

if($file and file_exists($file)) 

My thinking is that the answer can only be yes (true) if the file is in the current folder and doesn't have the .php extension. But, PHP novice that I am, I could be wrong about that. However, it seems to satisfy logic in that regard. If it really does, no need to rework that part unless it can be done more efficiently.

My real concerns are:

• There may be directives that allow any script to look outside its current folder for files along certain paths, even if only the filename.ext is given. Do these have any effect if not invoked within the script itself?
  
  
• Something, some PHP code perhaps, could be injected as the value for 'del' ($_GET['del']) in the query string that could somehow change how the rest of the script works.

[traq]

If it's all in the same folder, then using basename() should be sufficient, yes, but I think you're misunderstanding the [suffix] argument: it won't exclude .php files, it will just exclude the extension (e.g., basename("path/file.php", ".php") will return "file" instead of "file.php").

getimagesize() is a great function, which, ironically, I rarely end up using as a method to get an image's size. You'll only get a result if the file is an image, otherwise, it will return false. So, it's a good way to make sure a particular image is an image. If you want to make better use of the results, index [2] of the returned array will be an IMAGETYPE constant, and index [mime] will give the mime type.

Edit:

here's a list of the values that go with each IMAGETYPE constant (which seems to be really obscure information, but important if you expect to use the return value - I guess they might vary from server to server, so doublecheck).

[IMAGETYPE_GIF] => 1
[IMAGETYPE_JPEG] => 2
[IMAGETYPE_PNG] => 3
[IMAGETYPE_SWF] => 4
[IMAGETYPE_PSD] => 5
[IMAGETYPE_BMP] => 6
[IMAGETYPE_TIFF_II] => 7
[IMAGETYPE_TIFF_MM] => 8
[IMAGETYPE_JPC] => 9
[IMAGETYPE_JP2] => 10
[IMAGETYPE_JPX] => 11
[IMAGETYPE_JB2] => 12
[IMAGETYPE_SWC] => 13
[IMAGETYPE_IFF] => 14
[IMAGETYPE_WBMP] => 15
[IMAGETYPE_JPEG2000] => 9
[IMAGETYPE_XBM] => 16
[IMAGETYPE_ICO] => 17

[djr33]

I'm still not sure I understand the reason you want to approach it like this.

Can you not generate an absolute link using the location of the image and the image's name, regardless of where the script is? Or a link beginning with "/" because that will eliminate the need for subdomain complexity.