several questions in one-- ASP generated PDF, Securing site permission

[jtgurkin]

First,
I know that I can use an ASP page to generate a PDF file by writing the raw PDF data with a content type of PDF. I need to know where I can find the syntax of raw PDF data. If someone knows or could point me in the right direction, please help.

Second,
I need to generate some type of User Authentication script that will allow me to restrict access to a site based on the username/password combination the end user uses. I.E. I need to be able to allow some people to add data, others need to add and view data, and some only need to view. I need to be able to use some type of variable that will be passed along from page to page, or encoded on a cookie (which I don't know how to do effectively), to set the user access permisions.

Thanks,
jtgurkin

 

[TonyU]

First:
Check the guys at

http://activepdf.com/en/Products/WebGrabber/Start.asp

Second:
Include when creating the cookies the restricted field name on your database
if for example, your cookie looks like this
Response.cookies("user&quot("login&quot
Response.cookies("user&quot("password&quot
Response.cookies("user&quot("department&quot
etc...
Add
Response.cookies("user&quot("security&quot

And let's say your security codes are
1 or 10 etc... or whatever

on the pages you need to protect simply add as the first line on the page:

<%
if request.cookies(&quot;user&quot(&quot;security&quot <> 10 Then
response.redirect &quot;Somewhere_else.asp&quot;
end if
%>

Tho I'm sure there's a better way to tackle this, this is how it works for me...

^{There's never time to do it right, but there's always time to do it over!}

 

[Genimuse]

I recommend not storing user security info in their cookies because it's extremely easy to fake (I literally could just open up the cookie for the site in Notepad and change my (&quot;user&quot(&quot;security&quot to a different number).

Instead store the information locally in a database and just track the user via the session object (which uses a cookie, but all it contains is the current sessionid which can't be spoofed in a meaningful fashion).

So you'd instead have Session(&quot;login&quot, Session(&quot;password&quot, Session(&quot;department&quot, and Session(&quot;security&quot, all of which you would create after the user logs in.