Protecting Directory Contents Using ASP not NTFS permissions

[Ron Gibson]

Lets say I have a folder

members/3/

in this folder are images

I have a login page that connects to a database to retrieve user info.
After login the user is directed to a page that lists the files in the above
directory. Now lets say some other user goes to the directory and types in
members/3/image1.jpg he/she will now see the image. How can I stop this
without using ntfs permissions.

Any Ideas

Ron Gibson

 

[Ray Costanzo [MVP]]

Keep the images outside of the WWW area and then "stream" the binary data
back when you need an authenticated user requests an image.


http://www.aspfaq.com/show.asp?id=2276
That sample is for preventing hot-linking, which is different, but the
concept is the same. Instead of building the if/then off validating the
referer, you'd build it off whatever mechanism you're using to determine if
a user is logged in and is authorized to the image. Example:

If Session("LoggedIn") = 1 Then
''code to stream image
Else
Response.Redirect "/login.asp"
End If

Ray at work

 

[Evertjan.]

Curt_C [MVP] wrote on 21 dec 2004 in
microsoft.public.inetserver.asp.general:

dont store the image in the www path, store it outside of it and
stream it to the client.

Some dirty programming:


Rename a .jpg to .asp and put some code in front of the jpg code with an
ascii editor, like this:

<% Response.Expires = 0 %>
<% Response.Buffer=True%>
<!--#include virtual ="/testforlogin.asp"-->ÿØÿà....[etc jpg code]

As long as the jpg code has no <% this dirty programming works!
[some have many have not, just try.]

If it has, you will need the streaming solution.

Take care: no space or return after the > in >ÿØÿ

 

[Patrice]

I would really move away from such a "dirty" trick !!

Patrice

--

Curt_C [MVP] wrote on 21 dec 2004 in
microsoft.public.inetserver.asp.general:

dont store the image in the www path, store it outside of it and
stream it to the client.

Some dirty programming:


Rename a .jpg to .asp and put some code in front of the jpg code with an
ascii editor, like this:

<% Response.Expires = 0 %>
<% Response.Buffer=True%>
<!--#include virtual ="/testforlogin.asp"-->ÿØÿà....[etc jpg code]

As long as the jpg code has no <% this dirty programming works!
[some have many have not, just try.]

If it has, you will need the streaming solution.

Take care: no space or return after the > in >ÿØÿ

 

[Evertjan.]

Patrice wrote on 21 dec 2004 in microsoft.public.inetserver.asp.general:

I would really move away from such a "dirty" trick !!

I could have felt something for your point of view,
if you hadn't topposted.

As it is, such a dirty trick is a joy forever,
and is easy programming too.

 

[Jeff Cochran]

Curt_C [MVP] wrote on 21 dec 2004 in
microsoft.public.inetserver.asp.general:

dont store the image in the www path, store it outside of it and
stream it to the client.

Some dirty programming:


Rename a .jpg to .asp and put some code in front of the jpg code with an
ascii editor, like this:

<% Response.Expires = 0 %>
<% Response.Buffer=True%>
<!--#include virtual ="/testforlogin.asp"-->ÿØÿà....[etc jpg code]

As long as the jpg code has no <% this dirty programming works!
[some have many have not, just try.]

If it has, you will need the streaming solution.

The problem with this is you've created a non-standard file and can't
guarantee it will always work for users now and in the future.
Streaming is a more appropriate method for scalability and
compatibility.

Jeff

 

[Evertjan.]

Jeff Cochran wrote on 22 dec 2004 in
microsoft.public.inetserver.asp.general:

<% Response.Expires = 0 %>
<% Response.Buffer=True%>
<!--#include virtual ="/testforlogin.asp"-->ÿØÿà....[etc jpg code]

As long as the jpg code has no <% this dirty programming works!
[some have many have not, just try.]

If it has, you will need the streaming solution.

The problem with this is you've created a non-standard file and can't
guarantee it will always work for users now and in the future.
Streaming is a more appropriate method for scalability and
compatibility.

If you mean "client" by "user" [and not serverside ASP version], you are
incorrect.

The rendered "stream" of the .asp file has the same content as the
streaming version, so for the browser there is no difference.

Possibly new versions of ASP could stirr up errors, but so could the
streaming code.

Dirty coding, like the dying of links, have to be monitored, but that is
a webmasters fact of life anyway.