We have a DLL to handle password input for an Oracle / ASP application. The DLL also writes the session id to a cookie if the password is validated.
There are 4 developers, each of whom has their own development site on the web server, but all of whom use the same DLL - it being stored once on the site, and isn't duplicated as the ASP scripts etc are.
We have noticed, April 1st of all days, that the DLL does not write the cookie UNLESS we have a user logged on to the Web Server. At the moment we are sure that this has only begun to happen on April 1st, as we are not aware that we have had someone logged onto the web server permanently for the past 6 months! Also, another test server doesn't exhibit the problem.
Not writing the cookie means we get logged off as soon as we get to the main menu script. Log someone onto the Web server, and the DLL writes cookies. The odd thing is that the DLL still appears to handle the passwords OK regardless of someone being logged on or not. The line immediately before the cookie write is a SQL execute to write the session id to the database, and this still occurs.
Has anyone ever seen this behaviour before? We are at a loss, as the DLL permissions seem fine, and no one can figure out why simply having a user log onto the Web server box can affect IIS and the DLL.
Permissions seem to be set OK for Admins and System.
TIA
John
There are 4 developers, each of whom has their own development site on the web server, but all of whom use the same DLL - it being stored once on the site, and isn't duplicated as the ASP scripts etc are.
We have noticed, April 1st of all days, that the DLL does not write the cookie UNLESS we have a user logged on to the Web Server. At the moment we are sure that this has only begun to happen on April 1st, as we are not aware that we have had someone logged onto the web server permanently for the past 6 months! Also, another test server doesn't exhibit the problem.
Not writing the cookie means we get logged off as soon as we get to the main menu script. Log someone onto the Web server, and the DLL writes cookies. The odd thing is that the DLL still appears to handle the passwords OK regardless of someone being logged on or not. The line immediately before the cookie write is a SQL execute to write the session id to the database, and this still occurs.
Has anyone ever seen this behaviour before? We are at a loss, as the DLL permissions seem fine, and no one can figure out why simply having a user log onto the Web server box can affect IIS and the DLL.
Permissions seem to be set OK for Admins and System.
TIA
John
