Common connection string file

[egsdar]

Hi, On ASP 3.0 I was able to create a file conn.vbs where the connection
string lines to the db resides in, how can i do the same on ASP.Net?

The reason of this is to avoid modify the line in only one file instead of
do it in several web pages.

 

[Bob Barrows [MVP]]

Hi, On ASP 3.0 I was able to create a file conn.vbs where the
connection string lines to the db resides in, how can i do the same
on ASP.Net?

The reason of this is to avoid modify the line in only one file
instead of do it in several web pages.

You would do it in your web.config file, using the appsettings section.

There was no way for you to know it (except maybe by browsing through some
of the previous questions in this newsgroup before posting yours - always a
recommended practice) , but this is a classic (COM-based) asp newsgroup.
ASP.Net bears very little resemblance to classic ASP so, while you may be
lucky enough to find a dotnet-knowledgeable person here who can answer your
question, you can eliminate the luck factor by posting your question to a
group where those dotnet-knowledgeable people hang out. I suggest
microsoft.public.dotnet.framework.aspnet or the forums at www.asp.net.

 

[B@DJJ]

Bob is correct - .NET, use web.config, for ASP you could use the global.asa
file (to set an application session variable) though I'm not a big fan of
that myself. Our classic ASP DB calls go through a specific COM that handles
DB traffic - not all too pleased with that either, but I'm happier with that
than the global.asa route.

 

[Neil Gould]

Bob is correct - .NET, use web.config, for ASP you could use the
global.asa file (to set an application session variable) though I'm
not a big fan of that myself. Our classic ASP DB calls go through a
specific COM that handles DB traffic - not all too pleased with that
either, but I'm happier with that than the global.asa route.

Could you clarify why you aren't a fan of using global.asa (or session
variable, if that was what you were referring to)?

Thanks

 

[B@DJJ]

Sorry - just saw the post:

I'm more of a Mother Hen, really - Unless you really lock down the
global.asa so it can't be read by miscreants it's possible for someone to
access the global.asa and view it's contents (not directly via IIS (if
properly hardened) usually, but that's not where my concern is - I've had
consultants who thought it was a "good idea" to have a page that would
display the contents of any file via the browser simply by giving the page
the filename (Bad Programmer, Bad!)..... also, depending on what type of
security you want to implement at the DB-end, if the connection info is in
the global.asa anyone doing programming would have access to the userid/pswd
to your production db and it's never the ones that behave that you have to be
concerned about - same issue could arise with the web.config file in .net -
what I usually prefer is that either a COM or an Assembly (classic ASP or
..NET) be used to access the DB, properly locked down with very limited access
to the source code.

HTH

 

[Neil Gould]

Hi,

Thanks for getting back on this...

Sorry - just saw the post:

I'm more of a Mother Hen, really - Unless you really lock down the
global.asa so it can't be read by miscreants it's possible for
someone to access the global.asa and view it's contents (not directly
via IIS (if properly hardened) usually,

Are the miscreants that you refer to those with access to the server? It was
my understanding that those simply with access to a site can not read ASP
code in any of the files, but if there is a vulnerability, I'd like to be
aware of it. It would seem that, should such vulnerability exist, there
would be no way to "really lock down" the global.asa (or any other ASP
file). An example or reference would be appreciated.

but that's not where my
concern is - I've had consultants who thought it was a "good idea" to
have a page that would display the contents of any file via the
browser simply by giving the page the filename (Bad Programmer,
Bad!).....

Hmm, well, I've long wrestled with what delineates a page and have asked
here before (with somewhat differing responses). It was again my
understanding that a redirection to "foo.asp" would not make its server side
code visible. Being somewhat a novice with ASP, it would seem that exposing
the server-side contents would require quite a bit of deliberate
programming. For example, a page that reads "foo.asp", and parses the code
into browser-compatible responses. Perhaps I am missing your point,
though...

also, depending on what type of security you want to
implement at the DB-end, if the connection info is in the global.asa
anyone doing programming would have access to the userid/pswd to your
production db and it's never the ones that behave that you have to be
concerned about - same issue could arise with the web.config file in
.net - what I usually prefer is that either a COM or an Assembly
(classic ASP or .NET) be used to access the DB, properly locked down
with very limited access to the source code.

This makes sense, as it may narrow down the list of possible miscreants. Of
course, those doing programming could probably hijack the production
database anyway, no? ;-)

Neil

 

[B@DJJ]

Hi,

Thanks for getting back on this...


Are the miscreants that you refer to those with access to the server? It was
my understanding that those simply with access to a site can not read ASP
code in any of the files, but if there is a vulnerability, I'd like to be
aware of it. It would seem that, should such vulnerability exist, there
would be no way to "really lock down" the global.asa (or any other ASP
file). An example or reference would be appreciated.

My concerns are of the accidental release of the info - say someone backs up
the folders for the website and then "misplaces" the backup or some such
thing - you're right, a normal user with access only via IIS to the website
wouldn't be able to access the files directly.

Hmm, well, I've long wrestled with what delineates a page and have asked
here before (with somewhat differing responses). It was again my
understanding that a redirection to "foo.asp" would not make its server side
code visible. Being somewhat a novice with ASP, it would seem that exposing
the server-side contents would require quite a bit of deliberate
programming. For example, a page that reads "foo.asp", and parses the code
into browser-compatible responses. Perhaps I am missing your point,
though...

A redirection to another page wouldn't expose the server-side code in an asp
page, but what your saying (parsing the code, etc) is EXACTLY what they
thought was such a good idea (would help them with debuging and version
control...... Naughty, naughty and not a good idea) - I'm not as afraid of
the malicious attempts as those through foolishness or oversight.

This makes sense, as it may narrow down the list of possible miscreants. Of
course, those doing programming could probably hijack the production
database anyway, no? ;-)

Aye - if they had direct access to the Production DB, usually you'd want to
limit that down too, but the only safe DB is an offline DB and that doesn't
really advance the cause! There's no real way to protect a system 100% and
and still have it serve any usefull purpose - the best is to mitigate and be
on the defensive.

 

[Neil Gould]

A redirection to another page wouldn't expose the server-side code in
an asp page, but what your saying (parsing the code, etc) is EXACTLY
what they thought was such a good idea (would help them with debuging
and version control...... Naughty, naughty and not a good idea) - I'm
not as afraid of the malicious attempts as those through foolishness
or oversight.

There are a lot easier and more meaningful ways to achieve debugging and
version control than to create pages that could themselves have bugs and
version issues. While it doesn't surprise me that someone would come up with
such an idea, it does surprise me that they'd be able to verbalize it before
realizing the obvious problems with it.

Thanks for your thoughts... it seems that I'm on the right track in my
understanding of ASP...