You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
All our API's have optional api keys in them now. Not all clients send them yet, and we don't have a process to give them out.
But as a next step we should add a table with valid api keys in them. A simple table with a single column of type varchar(36) should be enough. The valid keys we have been giving out are uuid-like and all exactly 36 chars long. But we also tolerate a couple of ones like "test" or "geoclue".
A first use-case for this table is to decide if we log request stats for the key or not. Currently we have per-key logging for each of the three API's (search, geolocate, submit). We log either if there was no key provided <api>.no_api_key or if there was one <api>.api_key.<key>.
We had to change that for the geolocate API, as we got tons of random keys. These lead to the graphite backend to fall over. It generates about 4mb of data per metric, so thousands of random api keys quickly filled the disk.
Therefor I'd change the current scheme and use three metrics:
no api key provided
unknown api key provided
known api key provided
Only the last one would report the actual api key as part of the metric name. We still have the nginx access logs to see if new unsanctioned api keys come in.
Later the same table can be used to decline requests coming in from unknown api keys.
The text was updated successfully, but these errors were encountered:
Make the column at least varchar(40). The key we use in Fx Desktop for Google is a bit longer. Might want to support that one as a valid value as well.
All our API's have optional api keys in them now. Not all clients send them yet, and we don't have a process to give them out.
But as a next step we should add a table with valid api keys in them. A simple table with a single column of type varchar(36) should be enough. The valid keys we have been giving out are uuid-like and all exactly 36 chars long. But we also tolerate a couple of ones like "test" or "geoclue".
A first use-case for this table is to decide if we log request stats for the key or not. Currently we have per-key logging for each of the three API's (search, geolocate, submit). We log either if there was no key provided
<api>.no_api_key
or if there was one<api>.api_key.<key>
.We had to change that for the geolocate API, as we got tons of random keys. These lead to the graphite backend to fall over. It generates about 4mb of data per metric, so thousands of random api keys quickly filled the disk.
Therefor I'd change the current scheme and use three metrics:
Only the last one would report the actual api key as part of the metric name. We still have the nginx access logs to see if new unsanctioned api keys come in.
Later the same table can be used to decline requests coming in from unknown api keys.
The text was updated successfully, but these errors were encountered: