Link to home
Start Free TrialLog in
Avatar of Attack_Trax

asked on

Automating classic ASP cookie based authentication

I have a handful of classic ASP pages protected by basic ASP authentication using cookies and a database of username/passwords.

I want to be able to display one of the protected pages in a browser window which is opened using a URL from standard windows application - without the user needing to explicitly log on.

I guess I'm looking for a way of passing a Username/password from the application to the authenticate.asp script without the username and password being visible at any point?

Avatar of ThinkPaper
Flag of United States of America image

Take a look at using session variables.
You can store the username or userID (probably not pw) with sessions and not have to 'pass' it to each page.
Avatar of Attack_Trax


Thanks for your post.

I am currently using session variables to store the UserID once they have logged on.

What I'm looking for is a way of authenticating a user without them having to enter their Username and Password because if they have been sent to the page from the desktop application they don't need to be authenticated...
Is this on an intranet or is this a public facing website?
Public facing... but only accessed by a small number of users.

The authentication is to prevent casual browsers of the website accessing certain documents, and to track usage.
Are you in control of the asp pages?
I have full access to the ASP pages/source and can modify them if necessary - if that's what you mean by control?
what is this 'application' that you are using to send the user to the page?

If it's simply another page, then you could do a check for the 'referred page' using the session variable HTTP_REFERER
How are you displaying the page in your desktop application - in an embedded browser control?

Another thing - if the username is based of a windows account, you can also use the LOGON_USER session variable to grab the windows user account name and automatically use that as validation.
ThinkPaper - just a small thing but HTTP_REFERER and LOGON_USER are ServerVariabels, not Session.
The application is a Delphi win32 executable, so I'm guessing HTTP_REFERER will be blank?
Attack_Trax - how important is security, are you using SSL or is this really just to deter casual browsers?
And it has an embdedded browser control yes?
daveamour: The page is displayed by opening a window using the default browser.

ThinkPaper: Usernames are unfortunately not based on windows account names.

Also I don't have any control of the desktop application source/methods...
Ok and how important is security?
There is no SSL and nothing confidential is protected by the authentication, just some documentation and a rarely used forum.
Avatar of daveamour
Flag of United Kingdom of Great Britain and Northern Ireland image

Link to home
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Yeah that's pretty much how these pages work.

Thanks  - your idea is a possible solution. Each used of the Application does have separate credentials, although this could probably be changed for this scenario.

I was also considering creating an additional ASP page which is not linked to from anywhere on the site and reference only when the app opens the URL. This page could be used to effectively by-pass the authentication before re-directing the the relevant page.

Which do you think is the most secure of these two options? (or should that read 'the least insecure'!)
Thye are both pretty insecure but there are of course levels and degrees of security.

For example how do people normally logon to your ASP pages when they are doing so normally.  Lets say they logon as I described then the only difference between that method and my method is that your logon used the post form method and mine used the get method.  Unless you use SSL then both of these are transmitting usernames and passwords across the internet which are unencrypted.  If security is really important you should look at SSL.

Hope that makes sense.
Thanks - I opted for the method you suggested as the low security is not an issue and there is no prospect of using a more secure method of authentication.