Global.asa issue 1

[theniteowl]

Hi All,
I have been asked to investigate changes to one of our web apps. The app has a DB connection string setup through the global.asa file and is currently pointing to our production server rather than test even in our development enviornment.

I have made changes to the global.asa file to point to the test DB but it does not seem to pick up those changes and the app is still working with the production database.

Does the global.asa info get cached server-side and require a reset on that end for this change to be picked up?
I do not have administrative access on the web server and am unsure as to what I need to request the admins to do.

TIA.


It's hard to think outside the box when I'm trapped in a cubicle.

 

[Sheco]

if the change was in the application_onStart ...

Lets just say it was the session_onStart... How about using some bogus session variable to make a little test page?

Like maybe something like [tt]Session("foo") = "bar"[/tt]
... and then make a tiny one-line asp file: [tt]<%= "foo: "& Session("foo") %>

 

[theniteowl]

It is application_onStart.
Here is the code.

<script language=vbscript runat=server>
sub application_onstart
	application("connectionstring")="Provider=SQLOLEDB;Data Source=SQLSERVER;User ID=LOGONID;Password=PASSWORD"
end sub
</script>

When the app makes a connection to the DB is uses a line like this:

Connection.Open application("connectionstring")

I can modify the line in that particular asp file by putting the connection string in directly like:

'		Connection.Open application("connectionstring")
conn = "Provider=SQLOLEDB;Data Source=SQLSERVER\Dev;User ID=LOGONID;Password=PASSWORD"
Connection.Open conn

So when this particular page runs I get to the development
server rather than production but there are a number of pages throughout the application with similar calls.

The big thing is that the level of security accessing the pages is set by entries in a table in the database. I went directly into the dev database and added myself in so that I can see all of the screens to figure out all locations I will have to modify, but my ID is NOT in the production database so if it pulls production I do not get access to the pages. I do not want to modify all pages that do a DB call individually while working in dev and have to remember to change them back when I go to pre-prod.

I figure the setting in global.asa must be cached server-side and has to be flushed or the application is flagged on the server and something has to be stopped/restarted to pick up the changes. I have just never worked with global.asa previously and do not know what has to happen to let it pick up my changes.


It's hard to think outside the box when I'm trapped in a cubicle.

 

[Sheco]

The application onStart only runs on the very first Request to your web application.

Maybe you can copy everything down to your local development box and run a parallel instance of the site for development purposes?

 

[damber]

Usually with IIS6.0 it will reload the application when it notices a reasonable change in the global.asa (I think it checks size or something, as I've had it not do anything after replacing 1 char, but then work if I add a line etc).

If not then the admins can go to IIS explicitly unload from memory (in website properties). The next page request should then invoke the application_onstart.

Or you can write a little asp script to do it for you..

[tt]Application.Contents.RemoveAll [/tt] will get rid of the contents. You can then add the code inside application_onstart to the script for it to reload.

Or to change just one thing, just have the new page/script modify the value generated in Application_OnStart directly..
Application("YourConnStringetc") = "SomethingNew"

Then create a test page as per Sheco's suggestion using the application variable in question.

You could even have an ASP script that parses the current values in the Application Collection and allows the user to update the values. I do this with my site for ease of maintenance on some of the configuration.

A smile is worth a thousand kind words. So smile, it's easy!

 

[Sheco]

Does the site use session variables in a way that the users will lose their work/orders/login/etc if you reset the app or do something to cause it to be reset?

 

[theniteowl]

Well, I tried increasing the global.asa file size but it did not seem to pick up the change.
I tried putting the Application.Contents.RemoveAll line into a file by itself and executing it but it did not clear the problem either.

Adding the line:
Application("YourConnStringetc") = "SomethingNew"
did manage to get it clear though and once I removed the line from the page the site seems to have maintained the new connection.

I do not think the server picked up the changes in global.asa but at least I was able to change the value for the connection string. I will have to test from another device also to make sure it is not also affected by session variables and cookies as they have all three intertwined when checking to see if the page can be accessed by the current logon id and it looks to me as if the code has some flaws that could cause it to fail if a cookie does not already exist for the person trying to access the page when they are set with admin rights.
I remember vaguely someone talking about how they had to manually setup a cookie for a new user but had no idea at the time what they were referring to.

The code is flaky. My job is to go in and shut down any new submissions through the app and lock it down to just allow access to historical records. Now I will be able to actually see all of the screens to see where changes need to be made.

Thanks.




It's hard to think outside the box when I'm trapped in a cubicle.

 

[theniteowl]

Hmm, discovered something new with this global.asa issue.

The global.asa file contains ONLY this info:

<script language=vbscript runat=server>
sub application_onstart
    application("connectionstring")="Provider=SQLOLEDB;Data Source=SQLSERVER;User ID=LOGONID;Password=PASSWORD"
end sub
</script>

The security.inc file checks to see if the current logon ID has a cookie set for the application, if it does not then it checks the logon ID against a table in the database to see if the client has rights to the app and if they do it sets a new cookie for them with a limited expiration time.

The problem is that the connection string is defined in the global.asa file. When the security.inc file tries to make the connection it is erroring out trying to connect to the database because for some reason the connectionstring set in global.asa does not seem to exist.

From what I have read, anytime the server is restarted the first time someone access this application should cause the global.asa file to run the application_onstart section and set this value and that it SHOULD remain active until that value is acted on from another page or the server is restarted. But for some reason the value seems to get lost.

The effect is, when someone access the site who does not have a cookie set the app cannot look up their ID in the database either, thinks that the result was that they did not exist and sends them to an access denied page.
If they DO have a cookie they get in. The funny thing is the cookie though set to expire within 24 hours apparently never does or else no clients would be able to currently work in this app.

Anyone have thoughts to why this is happening?

I read that the global.asa file should be in the root directory of the application. In this case there is a scripts folder under inetpub then a subfolder for this particular division and then the applications folder there so global.asa is in inetpub\scripts\corporate\myapplication.

Does the application need to be defined on the server or have a virtual path so that the myapplication folder is treated as the root?

I got around the problem temporarily by simply executing the appropriate line once in another ASP file to set the connectionstring (thanks again damber) but I would like to find a more permanent solution.

Is there any benefit to setting this in the global.asa rather than doing it in an include file the individual pages use when making a connection to the DB?

I inherited the app. It was very poorly written and riddled with bugs. I am sunsetting the new entry portions of the code and leaving the lookup/reporting capabilities just so they can call up historical entries.

Thanks.


It's hard to think outside the box when I'm trapped in a cubicle.

 

[Sheco]

Does the application need to be defined on the server [...] so that the myapplication folder is treated as the root?

Yes. Using the IIS Administrator tool, right-click on your root folder and choose Properties from the popup context menu. A tabbed dialog will appear, switch to the Directory tab... now on the lower half of the tab along the right hand side are some buttons. There is one button that will either say "Create" or "Remove" depending on whether or not IIS considers this folder to be a web application root.

 

[damber]

theniteowl,

Is there any benefit to setting this in the global.asa rather than doing it in an include file the individual pages use when making a connection to the DB?

Not really - if you create a pseudo-logical data access layer/api using an include file then you can store it in there and be done with all the global.asa nonsense. As long as that is the only method used for accessing the database, (and included on the pages where necessary) then you will only need to define and manage it in one place.. same kind of benefit. The only thing you can't do is dynamically change the value via an ASP PAge (well, without parsing an asp include file) as you can an Application variable.. not that you would want to in any case!



A smile is worth a thousand kind words. So smile, it's easy!

 

[theniteowl]

Unfortunately I do not have administrative access on the server so cannot check the folders setup. I doubt it was ever set as a new application and someone just created the folder to put the scripts in when they began writing the program. I actually think the woman who did this just copied the app from elsewhere in the company and modified it to suit her needs. That version must have been setup correctly and she did not know enough to make it work correctly. Even then it took her 1.5 years to get the app working as buggy as it is.

There must be other methods of attaching to the database in the application otherwise even people who already have a cookie set so they can get INTO the app would not be able to pull back data if the connectionstring was not instantiated. I have to dive a bit deeper into the code to find out what else they are doing.

Until I managed to get past this connectionstring problem I could not even see the sites pages as I was immediately denied access so I have not gotten to the point of checking out actual data returned.
*Sigh*
It's so much easier to write my own code.

Thanks guys.

It's hard to think outside the box when I'm trapped in a cubicle.

 

[Sheco]

One of the ancestral folders of your "root" folder may itself be marked in IIS as a web application... such that the entire application is child/grandchild/greatgrandchild of some other app...

ASCII art: folders marked with astrisk are "web applications"
[tt]
webroot*
|
---folder1
| |
| ---file2
| |
| ---file3
|
---folder2*
| |
| ---folder3
| | |
| | ---file5
| |
| ---file4
|
---file1
[/tt]
In this example, all files and folders except folder2, folder3, file4, and file5 belong to the web application defined in folder webroot... requests for these resources will trigger \webroot\global.asa

... but requests for folder2 or anything under it will trigger \webroot\folder2\global.asa