Mysterious Google Maps API failures
-
The school recently acquired some Ruckus R700 WAPs and I've installed their Virtual SmartZone controller appliance, a VM running something CentOS- and Java-based that serves up a web app we can use to monitor and configure our WAPs.
One of the nice things the app can do is display a map pulled from Google Maps with a little green marker for each WAP whose GPS coordinates I've entered.
Except sometimes it doesn't. Sometimes I get a brief flash of map and markers that's quickly replaced by this:
and the console has some bogus message about missing API keys.
I've been working with Ruckus technical support to track down the cause; lots of hours spent watching their engineer beat his head against our terminal server via TeamViewer. Both of us thought we must be looking at some kind of network filtering issue, as the school LAN is part of a district-wide VPN and the only way out to the wider Web is via a proxy server. This was supported by the fact that when I set up a ssh port forward from my home to the Ruckus controller at the school, and opened the web app on my home machine, the map display worked fine.
However, tonight I've just found a way to make it work inside the school, and also to break it at home. It all comes down to what URL I use to open the web app.
Inside the school, it works properly if I get to it via
https://10.129.172.30:8443
https://ruckus:8443
https://kitchen:8443I get failed maps if I open the app via
https://ruckus-vsz.curric.lan:8443
https://ruckus-vsz:8443
https://rucku:8443
https://zzzzzz:8443
https://kaboodle:8443All of the above hostnames resolve to 10.129.172.30 inside the school.
From my PC at home, it works if I go via
https://127.0.0.1:8443
https://127.0.1.1:8443
https://kitchen:8443
https://ruckus:8443and fails via
https://kitchen.redacted.lan:8443 (sorry about the redaction, my lan's name is far too doxxy)
https://kaboodle:8443
https://rucku:8443
https://zzzzzz:8443where all those names resolve to 127.0.1.1.
If anybody can come up with a plausible rule that can predict whether a particular URL will succeed or fail, I'd like to hear about it.
-
You know, both OpenStreetMap and Bing Maps have improved a lot in the last few years.
-
@anonymous234 Maybe tell Ruckus that? It's their web app, not mine.
-
Maybe this:
Restrict your API keys to be used by only the IP addresses, referrer URLs, and mobile apps that need them
-
@flabdablet said in Mysterious Google Maps API failures:
If anybody can come up with a plausible rule that can predict whether a particular URL will succeed or fail, I'd like to hear about it.
If I read your post right, only the bare IP,
ruckus, orkitchenwork and everything else fails?
-
@Yamikuronue Yes, that's the current state of play.
Possibly relevant: there is no host named
kitcheninside the school network, and no host named anything for whichruckusis a prefix inside my home network.
-
@presidentsdaughter said in Mysterious Google Maps API failures:
Restrict your API keys to be used by only the IP addresses, referrer URLs, and mobile apps that need them
That's my current best guess for a plausible underlying mechanism, but I haven't yet worked out a plausible rationale for deciding which referers get accepted and which get rejected.
kitchenis a pretty unlikely name for Ruckus to have included on a referer whitelist; also, unless I've missed something, the Ruckus setup guide makes no mention of requiring their controller to be set up with any particular hostname.
-
@flabdablet looks like a DNS issue, the kind you face when setting up samba. Maybe something cannot resolve something easily, or in a single hop.
-
What does the IP resolves to in a reverse DNS query?
-
@presidentsdaughter said in Mysterious Google Maps API failures:
What does the IP resolves to in a reverse DNS query?
At school, 10.129.172.30 resolves to ruckus-vsz.curric.lan.
At home, 127.0.1.1 doesn't resolve in a reverse DNS query because its names are set via /etc/hosts. The hostname of the computer concerned is
kitchen. I would be more willing to believe that the box's actual hostname was relevant ifruckusdidn't work from home orkitchendidn't work from school, but both do.Since both of these IP addresses are in private ranges, reverse DNS queries run from outside home or school won't resolve.
-
It really sounds like the api key is bound to the ruckus, kitchen or 127.0.0.1.
-
Perhaps
kitchenis the hostname used by Ruckus internal testers/developers, so they included it in their whitelist?
-
@Gąska said in Mysterious Google Maps API failures:
Perhaps
kitchenis the hostname used by Ruckus internal testers/developers, so they included it in their whitelist?With all the cooks in there...
-
@Tsaukpaetra said in Mysterious Google Maps API failures:
@Gąska said in Mysterious Google Maps API failures:
Perhaps
kitchenis the hostname used by Ruckus internal testers/developers, so they included it in their whitelist?With all the cooks in there...
They're causing such a Ruckus?
-
@presidentsdaughter said in Mysterious Google Maps API failures:
Maybe this:
Restrict your API keys to be used by only the IP addresses, referrer URLs, and mobile apps that need them
Looking more and more likely that this is the root cause, regardless of the fact that the error is complaining about a missing API key, not a bad API key referer. I'm pretty convinced now that somebody at Ruckus failed to respond to this June update:
https://developers.google.com/maps/pricing-and-plans/standard-plan-2016-update
and that as a result there is random keyless coverage for domain names that Google chose, via the customarily opaque and unaccountable processes, to grandfather in.
-
...and posting that guess to our tech support case was enough to get our first-level support guy to cease faffing unproductively about and escalate the issue, after which a patch that fixed it got sent in about 40 minutes. Nice work from the dev team there.
