search

smeijer / leaflet-geosearch

A geocoding/address-lookup library supporting various api providers.
https://smeijer.github.io/leaflet-geosearch/
MIT License
1.02k stars 270 forks source link

Encrypted/Proxied Provider #332

Open IsabellaS09 opened 1 year ago

IsabellaS09 commented 1 year ago

Hello! I am using the Google Provider right now and I like the functionality of the geosearch, however I would like a way to use the component without exposing my API key on the public web.

Version numbers "leaflet": "^1.7.1", "leaflet-geosearch": "^3.6.0", "next": "12.0.7", "react": "17.0.2", "react-dom": "17.0.2", "react-leaflet": "^3.2.2",

I was attempting to set it up by making my own Provider implementation using my backend as a proxy but it seems like I would have to update the repo to be able to do that. Is this solution you would recommend or is there another way I should be able to encrypt my API key? Thank you!

darrenklein commented 1 year ago

@IsabellaS09 I was working on this issue a few months ago - if you take a look at my comments in this thread and PR, you can see what I was up to.

Issue - https://github.com/smeijer/leaflet-geosearch/issues/269 PR - https://github.com/smeijer/leaflet-geosearch/pull/311

I kind of hit a wall, though, as I'm not really much of a JS developer and wanted input from the repo's maintainer.

I haven't looked at this in a few months, but my recollection is that this basically revolves around the fact that the current implementation of the Google provider is not quite right - it works with the endpoint that Google intends for users to use with server to server geocoding, but not client to server geocoding. In the PR, I set things up to load the Google Maps client JS, which can then be used to to make the client-based requests; in the issue thread, I wrote about some of the discovery I did about protecting the API key - your key has to be exposed publicly (since the requests originate from the client), but you can configure your Google settings to restrict the domains from which requests will be accepted.

I'm not sure that my work on this is 100% complete, and I can't comment on if or when it would be accepted, as I'm not the owner of the repo and it will probably qualify as a breaking change for current Google provider users... but I'd encourage you to make any contributions you feel are appropriate, and I'd welcome any feedback you have about the discovery or PR work I did on this.

(and if you do want to experiment with this at all, make note of this comment in the PR - https://github.com/smeijer/leaflet-geosearch/pull/311#issuecomment-1150428075)

IsabellaS09 commented 1 year ago

@darrenklein Ah okay, yes I'll check out your PR!

darrenklein commented 1 year ago

In short, you can't obscure your API key, because this is a client library and so that key will always be exposed when making requests; however, Google does give you the ability to restrict the domains from which the key can be used, meaning that someone can't steal it and use it for another application. The reason that this does not work in the current Google provider implementation is that the endpoint that's currently being used does not support that kind of restriction because it's an endpoint that Google assumes you're using for requests originating from the server, and therefore the API key would never be publicly visible.

If you absolutely must hide your API key, then you might want to consider server-based geocoding. This repo is a client library, so extending it with some sort of server-side behavior wouldn't really be the right way to go. If you do opt for the server-to-server geocoding, somewhere in Google's documentation it says that that endpoint (which, again, is the one currently in use by this repo) is not really appropriate for handling dynamic user input, rather it's better suited for geocoding static addresses, like those stored in a database... it's in the documentation somewhere. I don't think it says why that's the case (and, clearly, it can handle dynamic input since it does work when used like that with this repo), but still worth noting - perhaps it's rate limited, I don't know... just going by what they say.