Working With Files Above Site's Root Directory

[Jerry]

I'm having just a bit of trouble wrapping my brain around the task of
working with folders that are above the site's root folder.

I let users upload photos (.jpg/.gif files) which can subsequently be viewed
on the site's pages. My hosting provider is requiring that any files my Web
app writes get written to a folder that is above the app's root folder (for
security purposes).

When writing the files I understand how to use MapPath to get the physical
path to the destination folder. So I think I'm okay on the uploading part.

But what I'm kind of hung up on is how to get my the aspx pages (<IMG
src=...>) to refer to the files in that folder. I'm dynamically assigning
the value of the src= property of IMG controls.

Do I need to create a virtual folder in the site? Is that the solution? Is
there another/better way? If I create a virtual folder, can I then ditch the
use of MapPath for uploading the files? Suppose I get all this to work with
a virtual folder, then haven't we totally defeated the whole point of
placing the folder above the site root (for security purposes)?

Bottom line - what do I need to do?

I'm kind of new Web app development, so any guidance or perspective is
greatly appreciated.

 

[Kevin Spencer]

Hi Jerry,

You wont be able to use Server.MapPath, as the file is outside of your web
application. It is more useful to think of the file location as "outside"
rather than "above" in this case, as the physical location of the directory
isn't important. The fact that it is outside your web app is important.

There are 2 kinds of directories in an ASP.Net app. One type is virtual
directories, or web directories. These are objects in the web server, as a
result of them having been defined as inside a web. They correspond to file
system directories, but are completely different in most respects. File
System directories can't have web server permissions assigned to them. File
System directories are invisible to the web server, unless they are mapped
to virtual directories.

The most typical way that a virtual directory is created is "by default,"
that is, as a result of being under the root web directory. They can also be
created by mapping directories outside the web app to a virtual directory
INSIDE a web app. This illustrates one of the differences between virtual
(web) directories and file system directories. Virtual directory permissions
pertain to HTTP requests for content. File System directory permissions
pertain to file system access of the directory.

So, in order to upload files, you're going to have to hard-code the full
(file system) directory location to upload them to. Your server-side code
can save the files to the physical file system directory that way.

To fetch them, you will also have to use the file system location. Rather
than creating an image tag that has a "src" attribute (which can only point
to a URL), you need to create an ASP page or HTTP Handler to fetch the
images from the file system, and return them, from inside your web. That ASP
page would be the "src" attribute of the image tag, and you can add
QueryString parameters to indicate which file it should fetch. It would set
the Response.ContentType property to "image/jpg" (or whatever MIME type the
image is), and save the file after opening it to the Response.OutputStream.
IOW, it would read the QueryString, find the file system location of the
image file, open it, and save it to the Response.OutputStream.

An HTTPHandler would also do the trick, but is probably a bit more than you
need for this requirement.

--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
Neither a follower
nor a lender be.

 

[Jerry]

Thanks Kevin - you always give great explanations.

 

[Kevin Spencer]

And Merry Christmas to you, Jerry!

--
Kevin Spencer
..Net Developer
Microsoft MVP
Neither a follower
nor a lender be.

 

[Nicole Schenk]

Hi Jerry,

You wont be able to use Server.MapPath, as the file is outside of your web
application. It is more useful to think of the file location as "outside"
rather than "above" in this case, as the physical location of the
directory isn't important. The fact that it is outside your web app is
important.

There are 2 kinds of directories in an ASP.Net app. One type is virtual
directories, or web directories. These are objects in the web server, as a
result of them having been defined as inside a web. They correspond to
file system directories, but are completely different in most respects.
File System directories can't have web server permissions assigned to
them. File System directories are invisible to the web server, unless they
are mapped to virtual directories.

The most typical way that a virtual directory is created is "by default,"
that is, as a result of being under the root web directory. They can also
be created by mapping directories outside the web app to a virtual
directory INSIDE a web app. This illustrates one of the differences
between virtual (web) directories and file system directories. Virtual
directory permissions pertain to HTTP requests for content. File System
directory permissions pertain to file system access of the directory.

So, in order to upload files, you're going to have to hard-code the full
(file system) directory location to upload them to. Your server-side code
can save the files to the physical file system directory that way.

To fetch them, you will also have to use the file system location. Rather
than creating an image tag that has a "src" attribute (which can only
point to a URL), you need to create an ASP page or HTTP Handler to fetch
the images from the file system, and return them, from inside your web.
That ASP page would be the "src" attribute of the image tag, and you can
add QueryString parameters to indicate which file it should fetch. It
would set the Response.ContentType property to "image/jpg" (or whatever
MIME type the image is), and save the file after opening it to the
Response.OutputStream. IOW, it would read the QueryString, find the file
system location of the image file, open it, and save it to the
Response.OutputStream.

An HTTPHandler would also do the trick, but is probably a bit more than
you need for this requirement.

Beautiful explanation!
Do you write?