Server side geo lookup

[nigel-bmlt]

Currently the admin javascript UI performs a geocode lookup (address to lat/long) on save. This creates a dependency on the BMLT maps API key to the admin javascript ui, and also seems to implicitly require the key restrictions to allow via referer (as the client IP addresses would be unknown).

The preference would be to provide this capability via a server side API, to avoid client side needing to know the maps key.

Am happy to tackle this as priority during the admin api rewrite if in agreement.

[jbraswell]

This makes sense. Would require an additional API key as google does not allow you to restrict an API key by both hostname and IP.

[pjaudiomv]

I thought it was server side and we moved it to client, I could be wrong. I do remember having a conversation round it

[jbraswell]

There are two existing usages of API keys.

One is server side. It lets you search meetings near a physical address. It geocodes the address. This functionality is broken, because most root servers have hostname restrictions on their API keys, causing this functionality to fail.

The other is client side. Occurs in the browser when saving meetings. This is the key that has hostname restrictions.

Server side geocoding makes more sense to me, but we will not be able to apply normal key restrictions. We cannot apply normal key restrictions to server side geocoding keys because most root servers are on shared hosting infrastructure and do not have truly static IPs. This means users would not be able to adequately restrict their keys by IP address.

If we are okay with users not being able to apply restrictions to their keys, and relying only on keeping them secret to prevent abuse, we could implement this.

However, we cannot remove the existing client side geocoding functionality. It would break all existing root servers, and root server admins do not know how to set up a new API key to fix it. The support burden would be substantial.