Where to store cgi app's db connection string?

Posted on 2006-06-07
Last Modified: 2013-12-25
What's the best way to load the database connection string into a cgi application?

The cgi app is an executable compiled from C++, written in-house.  It runs on IIS (cgi and ISAPI) & Apache on Windows, Apache on *nix. Multiple sites are running the same app on the same server with different configurations.

So where to put the connection string?

- Hard-coding is out because different sites access different databases.
- Other config settings are in the database but the database is not connected yet...
- The app runs on Windows & Linux so the registry is out.
- My favourite solution would be a MYAPP_DB environment variable but apparently environment variables cannot be set on a per-website basis - shame.

So the only thing left is a configuration file.  But where to put the file?

- There are multiple sites so putting it with the executable or hard-coded to 'C:\Program files\MyApp' is out.
- It can't go in the webspace (e.g. website root) because it's readable by all and it contains passwords, so that's a security risk

The best I can think of is an environment variable (or hard-code) with a path relative to the website root.

But I don't like this solution because:
- The file must be read for every hit.  It would be cached by the disk controller if read frequently enough but still...Is there a way to keep the database string in memory?
- Seems a bit over-complex for such a simple problem.

This must be an archetypal problem.  What do developers normally do in this situation?  Is there a better way?


Question by:jul17pri

    Author Comment

    Also, the MYAPP_CONFIG soluton doesn't enable the same app to run twice on the same site, and it might be necessary to run both /test and and /training and /live side-by-side.  Could always use the app folder name as the config file name e.g.
    ... so the app uses one of...
    c:\inetpub\wwwroot\SiteA\config\test .cfg
    c:\inetpub\wwwroot\SiteA\config\training .cfg

    Alternatively, instead of environment variables, the path to the master configuration file could go in another config file in the application root folder e.g.
    But now we're reading 2 files.  There must be an easier way...
    LVL 51

    Expert Comment

    I'd vote for a config file outside the diretory tree accessable by the web server.
    Then pass the path to that config as argument to your CGI.

    Author Comment


    How to pass the path is the main problem.  When you say 'pass the path to that config as argument', how is that done, in practice?

    LVL 51

    Accepted Solution

    oops, it's a CGI called via URL, right?
    Then I'd write a small wrapper to be called via URL which then calls the cgi with the path.
    But it makes thinks more complicated by adding another layer. Sigh.

    How about writing a small function in your cgi which uses a heuristic (anything you know how to acces a path) to find the proper configuration file? Something like:
       if exist /usr/app/my.conf then
         read it
       else if exist c:\my.conf then
         read it
       else ...
          echo "dumb"

    Author Comment

    > Then I'd write a small wrapper to be called via URL which then calls the cgi with the path.
    So each site has a tiny wrapper script that calls the executable

    cgi.exe "c:\wherever\my.conf"

    Hadn't thought of that one.  Thanks for the sugestion.  Works for CGI on Windows & Linux although not for ISAPI.

    But what your answer tells me is that there isn't another obvious standard way that everyone else uses but I don't know about...

    ...unless someone else has a better idea.  As CGI isn't a busy board I'll leave this question open until the end of the day...

    Author Comment


    Another option on Windows is to use a string rosource.  I think these can be compiled and linked to an executable seperately from the main build.  If not, it can be compiled into a resource DLL that sits with the executable.  This way, the connection string is loaded into memory along with the executable.  For ISAPIs it stays in memory so there's no need for a per-hit disk read.  Anyway, that's windows only so no good in this case...

    Going back to config files, if the cgi/isapi is mapped to a file extension then the file being processed could be anywhere in the webspace.
    e.g. if /cgi-bin/mycgi.exe is mapped to *.myhtml then the file being processed could be /this.myhtml, /sub/that.myhtml or /sub/the/other.myhtml

    so the config file needs to be relative to some known, fixed point like
    - c:\
    - / (web root)
    - the location of the executable

    That narrows it down.

    I still can't believe that web servers don't provide somewhere to store a database connection string, preferably encrypted on disk, loaded into memory & cached, available to the executable.  The majority of web apps need it after all.
    LVL 51

    Expert Comment

    > .. although not for ISAPI.
    ISAPI is proprietary "professional" software, you already paid for it, go and use the tools this software recommends.
    You do not expect that standards (like CGI) work flawless with ISAPI, do you?

    If you have a working CGI on windoze also, why do you care about ISAPI?

    > - / (web root)
    It's a bad idea to have config files in/below DocuemntRoot

    Author Comment


    > You do not expect that standards (like CGI) work flawless with ISAPI, do you?
    My applications interract with the web server via interfaces (c++ virtual classes) that are implemented for both ISAPI and CGI.  For each application, the Make file creates both CGI & ISAPI, and my customer can use whichever they prefer.

    > If you have a working CGI on windoze also, why do you care about ISAPI?
    Customers might prefer to use ISAPI because the executable is cached, no new processes are created, so it is faster. This is why ISAPI was created.  If they are running on *nix then they probably use the CGI because creating processes is not so expensive on *nix.

    > It's a bad idea to have config files in/below DocuemntRoot
    Good point.  When I say 'relative to...' I mean appending '..' to the web server root, so mapping



    It's relative to the web server's root, but outside the webspace.
    LVL 51

    Expert Comment

    it makes sense this way

    Author Comment

    Thankyou for joining me in this little discussion

    Write Comment

    Please enter a first name

    Please enter a last name

    We will never share this with anyone.

    Featured Post

    How your wiki can always stay up-to-date

    Quip doubles as a “living” wiki and a project management tool that evolves with your organization. As you finish projects in Quip, the work remains, easily accessible to all team members, new and old.
    - Increase transparency
    - Onboard new hires faster
    - Access from mobile/offline

    Preface This article introduces an authentication and authorization system for a website.  It is understood by the author and the project contributors that there is no such thing as a "one size fits all" system.  That being said, there is a certa…
    I will show you how to create a ASP.NET Captcha control without using any HTTP HANDELRS or what so ever. you can easily plug it into your web pages. For Example a = 2 + 3 (where 2 and 3 are 2 random numbers) Session("Answer") = 5 then we…
    The viewer will receive an overview of the basics of CSS showing inline styles. In the head tags set up your style tags: (CODE) Reference the nav tag and set your properties.: (CODE) Set the reference for the UL element and styles for it to ensu…
    HTML5 has deprecated a few of the older ways of showing media as well as offering up a new way to create games and animations. Audio, video, and canvas are just a few of the adjustments made between XHTML and HTML5. As we learned in our last micr…

    737 members asked questions and received personalized solutions in the past 7 days.

    Join the community of 500,000 technology professionals and ask your questions.

    Join & Ask a Question

    Need Help in Real-Time?

    Connect with top rated Experts

    21 Experts available now in Live!

    Get 1:1 Help Now