-2

I have all the images stored in a folder outside localhost i.e, on my Desktop. However, when I try to display image in php file using <img> tag and setting path to that location,it sets the defualt path of the image to "**localhost/Folder_name".**

How do I make script to read path from Desktop folder ,Not form localhost? I am using Ubuntu 14.10.

Mr Lister
  • 45,515
  • 15
  • 108
  • 150
Anurag Mishra
  • 11
  • 1
  • 4
  • Its not PHP but the web server which relies on the 'DocumentRoot' to server pages and images. anything outside is not defined in the webserver. – Lucky Chingi Nov 24 '15 at 14:53
  • You cannot directly refer to that location directly, which clearly makes sense from a security point of view. However the setup _does_ make sense, keep it like that. You just implement a little wrapper script that delivers the images, so that you do not reference the physical file in a URL, but that wrapper script together with some argument which identifies the images. That way you _can_ deliver the images, but stay in control, so can check for authorization and the like if you want to, and you do not hand out sensitive information like the physical location of your files. – arkascha Nov 24 '15 at 14:57

1 Answers1

0

This isn't a PHP issue, but rather a web server issue. The web server doesn't have access to files not located in its defined DocumentRoot. (i.e. /var/www).

The easiest thing to do would be to create a symlink inside the sites DocumentRoot that points to the directory on your desktop.

Or, a bit more complicate but probably more secure, you could setup send all image requests to a PHP file that will read the images from the desktop directory and stream them to the browser.

adear11
  • 935
  • 6
  • 11
  • 1
    Questionable. If this should be handled on file level at all (as you suggest with a "symlink"), then an `Alias` directive would be the cleaner approach. More transparent since more explicit and easier to control. – arkascha Nov 24 '15 at 14:59
  • Either way, you achieve the same thing. Unless you want to use PHP to stream the files, you've got to get them into the DocumentRoot of the site. – adear11 Nov 24 '15 at 15:02
  • A symlink requires that you enable following of such nodes first which is a potential security risk, and it is buried somewhere in your documents which means a migration or restructuring of an application will most likely miss it. An `Alias` is explicit and placed where it belongs: in the host definition. – arkascha Nov 24 '15 at 15:04
  • Sure, using a symlink is a potential security risk, but given that we're talking about saving images in a desktop directory, I'd wager that we aren't talking about anything that being uber secure is a huge concern. However, the option to follow symlinks can, and should, be defined in the host file/definition the same as an alias. Its use isn't buried any more than using an Alias for it. In fact, if you're talking about being clear, the symlink is more clear because you will see the symlink directory in the root when doing an `ls` as opposed to a 'magical' alias that is defined in the host – adear11 Nov 24 '15 at 15:11
  • Sorry, no, that really is completely wrong now. 1. Using a symlink means you have _two_ locations where to set this up: the host configuration _and_ the document location. That is less transparent per definition. 2. the symlink can clearly be buried, since such links can be anywhere deep in the file hierarchy of the document location and 3. a person responsible for a web server will hopefully treat web applications and the like as black boxes and _not_ modify stuff in there. That would be very unprofessional. Yes, probably this is not Fort Knox, but why suggest less good approaches? – arkascha Nov 24 '15 at 15:17
  • I guess we'll have to agree to disagree here. Everyone has a preference, and I prefer to be able to look at a URL and know exactly where the files being delivered come from, and I don't find their usage any more confusing or 'less transparent' than using an Alias. Also, honestly, using symlinks isn't really any more insecure either. All the symlink does is allow Apache to read from the directory. It has no write access, unless it is explicitly given, so there there isn't much risk. And if it becomes a risk, your site has been compromised anyway... but to each his own. – adear11 Nov 24 '15 at 15:29
  • An enabled symlink feature is a _huge_ security risk. There is a reason why it is disabled by default. Every user on a system can create symlinks to any location, even across file system boundaries. That means anyone can accidentally expose any file on a system! Also many modern web applications require to be able to write their own files (which is a joke anyway from a security point of view). That means that any application can create any symlink to any file on the system. now imagine what this means for an application that has a small security bug (so _all_ web applications). – arkascha Nov 24 '15 at 15:48