I have updated to the latest version of GMap in an attempt to fix this, but it doesn't seem to help. I have a site, example.com and when I enter example.com into the Rule section, I get a javascript warning that I need a new API key. Interestingly, this only happens when I access the site as an anonymous user and not as a registered user. Any ideas?

CommentFileSizeAuthor
#17 keys_url_864632_17.patch830 bytesgreenskin

Comments

gateone’s picture

Bump one up - sadly the same thing for me too...

greenskin’s picture

Hmm, can you paste the exact warning message you're given?

gateone’s picture

Priority: Normal » Critical

There are no errors. Only the JavaScript Warning appears that Google Maps API Key is wrong or missing when accessing a site. Can confirm: Keys definitively works no longer on any site with multiple URLs!!!

Crom’s picture

Ditto, I'm afraid. Exact message says "This web site needs a different Google Maps API key. A new key can be generated at "... followed by the API form URL.

Nightmare, a client has just dumped 15 domains that they want aliased to the main one and I need to launch in 2 days. Shout if I can help debug...

Not sure if this will help but I looked at the source code for the pages on the different domain aliases and none of the keys in the JS source match what I entered into the keys admin page. I then checked the original domain (for which a key was pre-entered into GMAP) and again, the key does not matched what I originally entered...but the original site works perfectly. Just none of the domain aliases that I've just entered.

Haven't had time to delve into the code yet but any help would be much appreciated.
Crom

Crom’s picture

Version: 6.x-2.x-dev » 6.x-2.0

Sorry, should have said that I'm using 6.x-2.0 unlike the original poster...but the problem is the same.

greenskin’s picture

Version: 6.x-2.0 » 6.x-2.x-dev

I might be off but what I'm understanding now as the issue is trying to use the same Google Maps API key for example.com and anotherexample.com. The Keys module simply serves the appropriate key to modules, not serve one Google API key for several domains. Google authenticates the key based on the domain so you will need to request a separate API key for each domain, then in Keys you specify what domain goes with what key. Again, maybe I'm totally off but this is what I'm understanding the problem to be.

Crom’s picture

Thanks for the quick response. Here's how I set it up.

Installed GMAP and it ran perfectly on the development domain.
Client springs 15 more domains on me so I found keys module.
Installed keys module and GMAP admin page now states that API keys are managed by the keys module.
I then requested individual google maps api keys for each of the new domains.
I entered them all into keys. Each new domain was entered with its corresponding key.
Then tested the sites and I get the api key warning on each of the new sites but it works on the original domain.

Crom’s picture

As I commented earlier, the actual key that is being inserted into the source code does not correspond to any of the keys that I entered...even on the original domain (which still works):

<script src="http://maps.google.com/maps?file=api&amp;v=2&amp;sensor=false&amp;key=ABQIAAAA8aN038M-lmHa4j6ArNxTaRSGyIDKh0-zVCmTkuAAjuqSED2HURSalMBABAZn-hmZv2OV33oM-DVTSQ" type="text/javascript"></script> 
greenskin’s picture

Can you look in your {keys_api} table and determine what is in the rule field that corresponds to the key that is being returned? Also, are you using MySQL or MySQLi?

Crom’s picture

You'll think I'm going mad but the key that is being returned is not in the keys_API table. However, all the keys that I entered with the correct rules are there.

# MySQL client version: 5.0.91
# Used PHP extensions: mysql

greenskin’s picture

Hmm, that is strange indeed. Perhaps it is an issue with GMap. What version of GMap are you using?

Crom’s picture

GMAP 6.x-1.1

greenskin’s picture

Open gmap.module and just above line 1243 (just before the return) put the following and refresh your page with the map.

<?php
var_dump($key);
?>

If the printed key is the same wrong one then determine in the same function which of the three $key is the one setting it. You can do that by putting a var_dump() or print command just after each of the $key lines.

This is the function GMap uses to get the key to use. So by determining where it is setting the wrong key we can fix it. This will also help us to determine whether the issue resides deeper in GMap or higher in keys.

Crom’s picture

Thanks very much for your help. I'll try this in the morning and report back...getting a bit late over here ;-)

marcdecaluwe’s picture

Sorry, wrong post.

marcdecaluwe’s picture

Version: 6.x-2.x-dev » 6.x-2.0

I have a problem with reckognizing URL's here. I always get the key for the domain which is defined in settings.php.
If I replace line 144 in keys.module

if (!isset($param['url'])) {
$param['url'] = keys_get_url();
}

by

if (!isset($param['url'])) {
$param['url'] = $_SERVER['HTTP_HOST'];
}

it seems to work ok. The function keys_get_url uses global $base_url to get the domain, but this is always the same. $_SERVER['HTTP_HOST'] delivers what I need. Don't understand why base_url is used in there.
Or am I missing something?

I use GMap 6.x-1.1

greenskin’s picture

Status: Active » Needs review
StatusFileSize
new830 bytes

Try this patch. I've re-worked the keys_get_url() and keys_get_domain() functions. The keys_get_url() should return the full URL then an appropriate key can be found based off of that URL. The patch fixes keys_get_url to return the correct full URL.

marcdecaluwe’s picture

I just tried and tested and the patch in #17 indeed does return the correct full URL. I'll leave it like this on my site, and will report if there's still an issue, but first tests seem to indicate this patch is ok.

Frederic wbase’s picture

Tested the patch of greenSkin and it works fine, thanks for the effort!

grts

fre

greenskin’s picture

Status: Needs review » Fixed

Committed.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.