Common connection string file

Discussion in 'ASP General' started by egsdar, Oct 5, 2008.

  1. egsdar

    egsdar Guest

    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.
     
    egsdar, Oct 5, 2008
    #1
    1. Advertising

  2. 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"
     
    Bob Barrows [MVP], Oct 5, 2008
    #2
    1. Advertising

  3. egsdar

    B@DJJ Guest

    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.
     
    B@DJJ, Oct 6, 2008
    #3
  4. egsdar

    Neil Gould Guest

    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, Oct 8, 2008
    #4
  5. egsdar

    B@DJJ Guest

    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
    >
    >
    >
    >
     
    B@DJJ, Oct 17, 2008
    #5
  6. egsdar

    Neil Gould Guest

    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
     
    Neil Gould, Oct 18, 2008
    #6
  7. egsdar

    B@DJJ Guest

    "Neil Gould" wrote:

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


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


    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.
    >
    > > 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? ;-)


    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
    >
    >
    >
     
    B@DJJ, Oct 20, 2008
    #7
  8. egsdar

    Neil Gould Guest

    B@DJJ wrote:
    > "Neil Gould" wrote:
    >
    >> B@DJJ wrote:
    >>> 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...

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

    --
    Neil
     
    Neil Gould, Oct 20, 2008
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Marcel Cugini

    Common connection for DALC's

    Marcel Cugini, Nov 18, 2003, in forum: ASP .Net
    Replies:
    0
    Views:
    348
    Marcel Cugini
    Nov 18, 2003
  2. Alex Smith
    Replies:
    3
    Views:
    442
  3. Denny
    Replies:
    1
    Views:
    789
  4. John Reye
    Replies:
    28
    Views:
    1,381
    Tim Rentsch
    May 8, 2012
  5. Jason Mellone
    Replies:
    3
    Views:
    105
    Jurko Gospodnetić
    May 7, 2014
Loading...

Share This Page