Common connection string file

[=?Utf-8?B?ZWdzZGFy?=]

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]]

egsdar wrote:

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.

--
Microsoft MVP - ASP/ASP.NET - 2004-2007
Please reply to the newsgroup. This email account is my spam trap so I
don't check it very often. If you must reply off-line, then remove the
"NO SPAM"

[=?Utf-8?B?QkBESko=?=]

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.

"egsdar" wrote:

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.

[Neil Gould]

B@DJJ wrote:

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

[=?Utf-8?B?QkBESko=?=]

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" wrote:

B@DJJ wrote:

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

[Neil Gould]

Hi,

Thanks for getting back on this...

B@DJJ wrote:

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