Every site that we develop uses a different domain for the SSL version of the site. Because of this, we are left with the choice of either using a different module for Google Maps, or drop support for SSL. Obviously, we don't want to drop support for SSL for security reasons, and we really want to keep using GMap. So, I've created a patch that provides the ability to have a separate key for SSL.

I don't use the keys module, so cannot fully test that functionality, but I did add to the array that it submits to the key_service hook. In every case, if no SSL key is provided, it reverts back to the non-SSL version (to prevent breaking sites on any module update).

Let me know what you think... I do think this would be a nice addition to those that use SSL on different domains.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

mikesir87’s picture

Title: Use Separate Key for SSL (with patch) » Better SSL support - use separate key and fix marker path
FileSize
5.28 KB

Ok. I have one more additional change. As I was testing, I found that the path to the marker icons could be incorrect based on your SSL configuration.

CASE:
Non-ssl Drupal root: http://www.sample.com
SSL Drupal root: http://secure.otherSample.com/sample.com/

The gmap_markers.js builds the path into the JS. The path, if generated in non-ssl is /sites/default... But, this won't work on the SSL version. I modified the JS generation to not include the path in the file, but add it using drupal_add_js whenever the gmap_markers.js is loaded, which allows the path to be more dynamic.

The attached patch is a modified version of the previous patch.

mikesir87’s picture

Not to be a pain... but any thoughts?

waverate’s picture

Just to be clear, is this patch required because are you displaying a map on a secure site and connecting to Google Maps using HTTPS?

mikesir87’s picture

It's required because we have a completely different domain for our SSL server. Since the domain is different, the Google Maps API key is invalid, and we have to have another one. So, this patch gives you the ability to use a different key if you are using SSL.

An example of our setup...
Non-SSL: http://www.example.com
SSL: https://secure.server.com/www.example.com/

waverate’s picture

Michael,

Thanks for the reply.

I didn't think you could connect to the Google Maps API using HTTPS without having a Google Maps API Premier account.

mikesir87’s picture

That is true, but we're still using a free API key. True, it alerts the user to non-secure connections, but oh well... But, it still requires us to have a separate key since the domain is different. :-\

mikesir87’s picture

That is true, but we're still using a free API key. True, it alerts the user to non-secure connections, but oh well... But, it still requires us to have a separate key since the domain is different. :-\

waverate’s picture

Michael,

Well if it is an unsecure connection, why don't you revert back to your non-SSL domain name?

mikesir87’s picture

Well, it doesn't make much sense to revert back to the non-SSL domain name for that specific page. We should be able to stay in the SSL. Besides, it still keeps any session/cookie transactions between our domain and the server secure. The only thing that isn't is the communication with Google (which won't involve our session cookie). It's our policy that whenever a user is logged in, they are required to be in SSL. But, a visitor (anonymous user) is not required to be in SSL.