views:

72

answers:

3

I have a web site with many virtual hosts and each registered with several domain names (ending in .org, .de), site1.mysite.de, site2.mysite.org

Then I have different templating systems based on several programming languages (perl and php) in use on the web server.

The Google Maps Api requires a unique Google Maps api key for each vhost.

I want to have something like a web-server wide variable $goomapkey that I can call from inside my code.

In PHP code, Now I have a kludgy case-analysis solution like

 $domain = substr($_SERVER['SERVER_NAME'], -3);
 if (".de" == $domain){
   //if ("xxxxxx" eq substr($ENV{SERVER_NAME}, 0, 5)){

   //  $gookey = "ABQIAAA...";
   //} else {
     //site1.de   
     $gookey = "ABQIAAAA1Js...";
   //}
 } elseif ("dev" == substr($_SERVER['SERVER_NAME'], 0, 3)){
   //dev.mysite.org
   $gookey = "ABQIAAAA1JsSb...";
 } else {
   //www.mysite.org
   $gookey = "ABQIAAAA1JsS...";
   //TODO: Add more keys for each virtual host, for my.machinename.de, IP-address based URL, ...
 }

... inside my php-based CMS. A non-ideal solution, because it is, php-only, and I still have to set it at several html templates inside the CMS, and there are too many cases.

I want the google maps api key to be set by the apache web server who examines the request *early in the request loop before any php page template code is constructed and evaluated.

  • is an environment variable a good solution?

  • which technology should be used to set the $goomapkey variable?

I'd prefer mod_perl2 Apache request handler, but the documentation is confusing (many API changes in the past ). Which Apache module could I use?

  • Is there a built-in Apache module that does the same thing?
A: 

If you try to populate the variable via mod_perl2, then it won't be available to PHP - similarly, your PHP include files are not available to PERL.

An environment variable looks like a good compromise - unless you are already loading comon data from data files / a database.

Is there a built-in Apache module that does the same thing?

Yes - mod_env and the SetEnv directive

C.

symcbean
Ah , I see- I could write a mod_perl2 handler for "Post Read Request" phase,or use module mod_setenvifhttp://httpd.apache.org/docs/2.0/mod/mod_setenvif.html Thanks anyway!
knb
+4  A: 

Surely this is a little overkill for only a few domains? I mean, you've obviously had to go through the process of applying for a key for each domain, why not just use each key in each project independently?

The most elegant solution would be to make the switch to Google Maps API v3, which no longer requires an API key.

TheDeadMedic
Thanks, sounds good, I'll look into the GM API v3.
knb
+1  A: 

Is an environment variable a good solution?

I'd hesitate to use environment variables to store a "key", except API keys aren't secret (anyone can see it with "view source"), so it seems vaguely sensible.

Whether you think it's a "good" idea is different matter — it's a layering violation, but so's everything else. If your web framework (or whatever you're using) has some sort of site config, that's the obvious place to put it. You can have the config code load it from the environment variable, but if you keep it in the config then it's much easier to change later

I'd prefer something like

$apikeys = array(
  "site1.de" => "...",
  "dev.mysite.org" => "...", 
  "www.mysite.org" => "...",
  "" => "...", // default
);

Then the code loops over the array, finds the longest suffix match, and uses the corresponding key. It has the advantage that it's easier to port between different languages (you can even write genapikeys.pl which writes gmapapikeys.php). I also don't think there's any point having a default key — IIRC Google Maps rejects your request if the key doesn't match the "Referer".

A more general solution would be to reverse the hostnames (i.e. de.site1, org.mysite.www); you can then have "com.hostingcompany.www/mysite/".

Of course, IP addresses are in reverse order, and IPv6 is a load of fun. I'm not sure if API keys support either, though, so it might be irrelevant.

tc.
Indeed that was what I had in mind when I wrote my posting. Thanks!
knb