Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Logitude Latitude necessary for mapping function to work? Available outside of US? #5174

Closed
ChurchCRMBugReport opened this issue Mar 8, 2020 · 16 comments
Closed

Logitude Latitude necessary for mapping function to work? Available outside of US? #5174

ChurchCRMBugReport opened this issue Mar 8, 2020 · 16 comments
Labels
Design Decision Documentation enhancement Feature: Geographical / Maps Security
Milestone
4.0.3

Comments

@ChurchCRMBugReport
Copy link

I created a Google Maps API key yesterday (so it's brand new). I have addresses that, when entered into Google are mapped correctly. In fact, when I am looking at a single family entry in ChurchCRM, and choose to display them on the map, it invokes Google Maps and displays correctly.

BUT displaying all the families shows NOTHING and updating the Longitude and Latitude shows nothing. Our church is in France. Is this why showing all the families doesn't work?

Collected Value Title Data
Page Name /MapUsingGoogle.php
Screen Size 864x1536
Window Size 762x1519
Page Size 1429x1519
Platform Information Linux gremlins.o2switch.net 3.10.0-962.3.2.lve1.5.24.8.el7.x86_64 #1 SMP Fri Jan 4 06:55:54 EST 2019 x86_64
PHP Version 7.2.28
SQL Version 10.0.38-MariaDB
ChurchCRM Version 4.0.2
Reporting Browser Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:73.0) Gecko/20100101 Firefox/73.0
Prerequisite Status Missing Prerequisites: ["Mod Rewrite"]
Integrity check status {"status":"success"}
Apache Modules mod_rewrite,mod_mime,mod_headers,mod_expires,mod_auth_basic
@MrClever
Copy link
Collaborator

MrClever commented Mar 8, 2020

Mapping features definitely work outside en_US locales (I’m using successfully, and reliably here in en_AU - greetings from Oz!). When you say showing all families displays “nothing” do you mean the map area is blank (no map etc) or you mean the map displays but no pins are rendered etc? A screen shot might be useful, as would anything relevant from the /logs/*-app.log in your ChurchCRM directory.

@dleigh
Copy link

dleigh commented Mar 9, 2020

A map with no pins. I'll get a screen shot and logs. Thanks.

@dleigh
Copy link

dleigh commented Mar 9, 2020

2020-03-09 09_42_01-
churchcrm.zip
Ok, here's the screenshot and the logs. Thanks for your help!

@MrClever
Copy link
Collaborator

Odd - there isn't anything in the logs that point to a problem (other than occasional MySQL connection saturation). If you open QuerySQL.php on your ChurchCRM setup (Left menu: Query/Reports -> Query Menu -> Run a Free-Text Query (top right)" then enter the following query select fam_ID,fam_Latitude,fam_Longitude from family_fam. You should see three columns with a number, then latitude and longitude for each family address.

A single column with only numbers indicates the system was unable to resolve the addresses to lat/long co-ordinates.

No need to show results; but it might help narrow down where the problem is.

@crossan007 crossan007 added this to the User Support milestone Mar 10, 2020
@dleigh
Copy link

dleigh commented Mar 12, 2020 via email

@dleigh
Copy link

dleigh commented Mar 12, 2020 via email

@dleigh
Copy link

dleigh commented Mar 12, 2020 via email

@MrClever
Copy link
Collaborator

Thanks for the additional information @dleigh. The way I set up Google Maps API keys is not to restrict the API key (it can call any API I have enabled) and not to set any "Application restrictions" (ie, HTTP referrer, IP address).

The API keys I set up have the following Google Maps APIs enabled:

  1. Geocoding API
  2. Maps Embed API
  3. Maps JavaScript API
  4. Maps Static API

This will only require a single API key and allows the maps features work correctly in the ChurchCRM application.

Some commentary on security

Yes, this theoretically means if someone got hold of my API key they could max out my free map API calls and leave my ChurchCRM map dead in the water (or burn a hole in my Google API budget...which is why I set monthly $$ limits). Then I could just generate a new key, and move on. Having said that, the geocode utilities for Google Maps used in ChurchCRM smoosh the API interaction into a JSON payload communicated over HTTPS:

/vendor/geocoder-php/google-maps-provider/GoogleMaps.php extract...

...
    const GEOCODE_ENDPOINT_URL_SSL = 'https://maps.googleapis.com/maps/api/geocode/json?address=%s';
...
    const REVERSE_ENDPOINT_URL_SSL = 'https://maps.googleapis.com/maps/api/geocode/json?latlng=%F,%F';

The API key is never transmitted in the clear or as part of a GET request when polling Google (even if your ChurchCRM isn't set up with an SSL certificate), as can be seen above. The only information that could be sniffed off the wire is (possibly) the server being connected to over HTTPS (ie, maps.googleapis.com)* and the TCP headers etc. Consequently, unless you're worried about a HTTPS man-in-the-middle (MITM) attack or your database getting hacked (it's not publicly accessible right?) then the risk we're talking about, where your API key is compromised, is extraordinarily small. I would posit it's far more likely a ChurchCRM admin account with a weak password is compromised...but now we have 2FA ❤️

* Domain name MAY be transmitted in clear (if SNI extension is used in the TLS handshake) but URL (path and parameters) is always encrypted.

@dleigh
Copy link

dleigh commented Mar 13, 2020

Thank you @MrClever for the info - very detailed and helpful. I can confirm that this works.

My own opinion is that, at least for Google (since I don't know how Bing works), it would seem that having 2 keys (one for JavaScript and one for Geocoding) would be more in line with how Google expects the keys to be used. I had also run my issues by Google support and they indicated that a solution that doesn't allow for the use of two separate keys is (in their words) "wrongly developed". And, of course, not to have the referrer domain or source IP restrictions grants you a "warning icon" in the Google developer's console. So while it would be a bit more complex, it seems that's the recommended route - though I can see value in the simplicity of one key as well.

Regardless of a one or two key solution, I do believe this whole process would benefit from more documentation. Considering how many different ways one can set this up and that Google pushes you to add restrictions, it's unfortunately a bit easy to set it up incorrectly - leading to time-consuming frustration. So hopefully this thread will help others and perhaps the documentation could be adjusted to make reference to it.

Thanks again for your detailed help!

@crossan007 crossan007 modified the milestones: User Support, Backlog Mar 14, 2020
@crossan007
Copy link
Contributor

Thanks @dleigh and @MrClever for the detailed research and notes.

At first glance, I agree with implementing the two key approach, and have updated the labels and milestone for this issue, pending confirmation of Google API key best practices.

I also think the API key would also be a prime candidate for at rest encryption in the database, since it is technically a "secret".

crossan007 added a commit that referenced this issue Mar 15, 2020
@crossan007
update all google maps api keys so that geocoding uses a different ke…
591fa6d 
…y from rendering

This largely arises out of the discussion at #5174 (comment)

Geocoding API keys should be restriced so that only the IP of the ChurchCRM server may execute queries, whilst the rendering key should be restricted so that only the ChurchCRM URL is permitted as an HTTP Referrer.

Need to do some more work on this (migrations/documentation) before it's ready to merge.
@crossan007 crossan007 mentioned this issue Mar 15, 2020
Merged
@crossan007 crossan007 modified the milestones: Backlog, User Support Mar 16, 2020
@crossan007
Copy link
Contributor

I made a revision to the wiki attempting to summarize the discussion here; as well as take into account the changes pending for the 4.0.3 release: https://github.com/ChurchCRM/CRM/wiki/Geographic

@crossan007 crossan007 mentioned this issue Mar 16, 2020
Closed
@dleigh
Copy link

dleigh commented Mar 16, 2020

I made a revision to the wiki attempting to summarize the discussion here; as well as take into account the changes pending for the 4.0.3 release: https://github.com/ChurchCRM/CRM/wiki/Geographic

Application Restrictions

IP Addresses - supply the IP Address of your ChurchCRM server

In my experience, this won't work. You have to remove the IP Address restriction to use a single API key for both the Geocoding AND the JavaScript APIs - hence the discussion.

@crossan007
Copy link
Contributor

@dleigh this statement will be true in the wiki when we release 4.0.3, which splits out the API keys :-)

@dleigh
Copy link

dleigh commented Mar 16, 2020

Ah - ok, I understand. Thanks.

@crossan007 crossan007 modified the milestones: User Support, 4.0.3 Apr 1, 2020
@crossan007
Copy link
Contributor

@dleigh 4.0.3 is released - can I close this?

@dleigh
Copy link

dleigh commented Apr 1, 2020

Sure. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Design Decision Documentation enhancement Feature: Geographical / Maps Security
Projects
None yet
Milestone
4.0.3
Development

No branches or pull requests
4 participants
@MrClever @dleigh @crossan007 @ChurchCRMBugReport