Securing uploaded documents

[Dan]

I already check the ext bwig, the problem is they are not necessarily
genuine pdf's. I've been searching for mime
sniffing code like u suggested Dan, but so far can only find
resources for .net

Just set it to application/octet-stream as Bwig suggested, then the browser
can deal with as it sees fit.

Trying to roll your own MIME sniffing code in ASP is going to be a mess -
without a COM component that you can program against to do it for you it's
not worth even starting. The MIME sniffing I was referring to is already in
IE7 and IE8, they will attempt to determine the appropriate application to
open a file that is downloaded.

 

[Bwig Zomberi]

I already check the ext bwig, the problem is they are not necessarily
genuine pdf's. I've been searching for mime
sniffing code like u suggested Dan, but so far can only find
resources for .net

That will be very expensive in terms of server resources. It will not be
scalable.

 

[Dean g]

Damn, 2 out of 3 problems solved is still good.

Thanks for the help guys, i just wish i knew why half the pdf
files display garbage on the screen even though they are
genuine pdf's. i guess thats a question for another group
though.

regards,
Dean

 

[Bwig Zomberi]

Damn, 2 out of 3 problems solved is still good.

Thanks for the help guys, i just wish i knew why half the pdf
files display garbage on the screen even though they are
genuine pdf's. i guess thats a question for another group
though.

I had this problem with Opera. In a newer version, it got solved.

Just ensure that you set the content type properly on the server-side
and you are not writing anything other than what is in the PDF to the
browser. To be sure that the entire ASP code is between one set of <%
and %>. Do not use nested code. Do not write any HTML or set any cookies.

On the client side, ensure that Adobe Reader is installed properly and
plugins are available for all browsers.

If the problems persist, then it is problem with the PDFs. You could go
to alt.txt.pdf. However, you will need to host the PDF and provide a
link so they can check it out.

 

[Dan]

I had this problem with Opera. In a newer version, it got solved.

Just ensure that you set the content type properly on the server-side and
you are not writing anything other than what is in the PDF to the browser.
To be sure that the entire ASP code is between one set of <% and %>. Do
not use nested code. Do not write any HTML or set any cookies.

On the client side, ensure that Adobe Reader is installed properly and
plugins are available for all browsers.

If the problems persist, then it is problem with the PDFs. You could go to
alt.txt.pdf. However, you will need to host the PDF and provide a link so
they can check it out.

The other thing you can do is use Response.Buffer = true, and then prior to
sending the headers clear the buffer first just in case there are any CR/LF
characters from inline ASP above that piece of code. Or just make sure you
always put inline ASP code fully inline, eg.

<%
blah blah
%>
<%
more blah
write headers
write binary data
%>


will actually put a single CR/LF combination before the data, because there
is a CRLF outside of the ASP tags. The same can be written as


<%
blah blah
%><%
more blah
write headers
write binary data
%>

and not insert the CR/LF.

It's also worth checking this wherever you send out a DOCTYPE headers in
normal HTML, if the DOCTYPE isn't on the first line of the output then some
browsers will ignore it.

 

[Bwig Zomberi]

The other thing you can do is use Response.Buffer = true, and then prior
to sending the headers clear the buffer first just in case there are any
CR/LF characters from inline ASP above that piece of code. Or just make
sure you always put inline ASP code fully inline, eg.

<%
blah blah
%>
<%
more blah
write headers
write binary data
%>


will actually put a single CR/LF combination before the data, because
there is a CRLF outside of the ASP tags. The same can be written as


<%
blah blah
%><%
more blah
write headers
write binary data
%>

and not insert the CR/LF.

It's also worth checking this wherever you send out a DOCTYPE headers in
normal HTML, if the DOCTYPE isn't on the first line of the output then
some browsers will ignore it.

I think that if you use two sets of <% and %>, it adds a new line
character, which will totally wreck the PDF. It should be like

<%
clear
buffer
content type
header
binary write
flush
%>

No spaces before or after the delimiters.

 

[Evertjan.]

Bwig Zomberi wrote on 03 jun 2010 in
microsoft.public.inetserver.asp.general:

I think that if you use two sets of <% and %>, it adds a new line
character, which will totally wreck the PDF. It should be like

<%
clear
buffer
content type
header
binary write
flush
%>

No spaces before or after the delimiters.

Use:
Response.Clear
....
Response.end

For years now
[last correction date of the inc file 21/5/2005]
I have succesfully used this:

function streamPdf(strFileName)
Response.Clear
strFilePath=server.mappath(strFilename)
Set objStream = Server.CreateObject("ADODB.Stream")
objStream.Open
objStream.Type = 1
objStream.LoadFromFile strFilePath
Response.ContentType = "application/pdf"
Response.BinaryWrite objStream.Read
objStream.Close
Set objStream = Nothing
Response.end
end function

 

[Dan]

I think that if you use two sets of <% and %>, it adds a new line
character, which will totally wreck the PDF. It should be like

Nope, only if you put a new line between the tags. Feel free to try it out -
I've already done so on IIS6 and there is no implied newline at tag
ends/starts.

<%
blah
blah
%><%
blah blah
%>

does not add a newline.

I often use includes too, so for instance will do things like

<%
blah blah
%><!-- #include file="file.asp" --><%
blah blah
output binary data
%>

and again there will be no newlines before the binary data.

 

[Bwig Zomberi]

Nope, only if you put a new line between the tags. Feel free to try it
out - I've already done so on IIS6 and there is no implied newline at
tag ends/starts.

<%
blah
blah
%><%
blah blah
%>

does not add a newline.

Your code does not add a new line. I usually put separate the <% %>
pairs for readability of the code. That adds a new line. The OP may be
doing the same in his code. He may not immediately see that you have
neatly avoided that pitfall by keeping it together;-)

I have faced a similar problem with writing RSS feeds using ASP. The
first line of XML files should start with <?xml .... or something. My
regular code convention would break that.

 

[Dan]

Your code does not add a new line. I usually put separate the <% %> pairs
for readability of the code. That adds a new line. The OP may be doing the
same in his code. He may not immediately see that you have neatly avoided
that pitfall by keeping it together;-)

I thought I'd made it clear enough in my earlier reply, and that you were
stating I was wrong, hence the above followup. If you look at my 2 examples
you can see the difference, and that was my point.

I have faced a similar problem with writing RSS feeds using ASP. The first
line of XML files should start with <?xml .... or something. My regular
code convention would break that.

Ah, yes, RSS, that's another place I learnt to not put newlines outside of
code blocks ...

 

[Dean g]

Awesome guys, you were right once i tighten up all my code
blocks it started working. Make that 3 out 3 problems solved.

Thanks alot

 

[Bwig Zomberi]

I thought I'd made it clear enough in my earlier reply, and that you
were stating I was wrong, hence the above followup. If you look at my 2
examples you can see the difference, and that was my point.

Speed reading. My bad.

ContentType, not DocType, your bad.

Another thing: The PDF ng is comp.text.pdf, not alt.txt.pdf. My bad.

 

[Bwig Zomberi]

Speed reading. My bad.

ContentType, not DocType, your bad.

Another thing: The PDF ng is comp.text.pdf, not alt.txt.pdf. My bad.

Apologies for the bads. Just looked it up. I will promise never to use
it again.

 

[Dan]

Apologies for the bads. Just looked it up. I will promise never to use it
again.

I hope that isn't a promise not to use DOCTYPE declarations in your HTML
pages

 

[Bwig Zomberi]

I hope that isn't a promise not to use DOCTYPE declarations in your HTML
pages

No, you are right. That was clearly in a different context. I thought
you suggested doctype for PDF files.

 

[Dan]

No, you are right. That was clearly in a different context. I thought you
suggested doctype for PDF files.

I guess I need to break my replies up a bit more then, but in my defensive I
did put "normal HTML" in the same line

It's a shame this newsgroup will be gone soon