Where to store cgi app's db connection string?

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?


Who is Participating?
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"
jul17priAuthor Commented:
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...
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.
Free Tool: SSL Checker

Scans your site and returns information about your SSL implementation and certificate. Helpful for debugging and validating your SSL configuration.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

jul17priAuthor Commented:

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?

jul17priAuthor Commented:
> 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...
jul17priAuthor Commented:

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.
> .. 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
jul17priAuthor Commented:

> 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.
it makes sense this way
jul17priAuthor Commented:
Thankyou for joining me in this little discussion
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.