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.

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

Add table for valid api keys #140

Closed
hannosch opened this issue Mar 13, 2014 · 2 comments
Closed

Add table for valid api keys #140

hannosch opened this issue Mar 13, 2014 · 2 comments
Assignees
Labels

Comments

@hannosch
Copy link
Contributor

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.

@hannosch
Copy link
Contributor Author

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.

@hannosch
Copy link
Contributor Author

hannosch commented May 5, 2014

Closed via #177 and #183.

@hannosch hannosch closed this as completed May 5, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants