Skip to content

Make api-key data more generic in order to attach more info to it #3

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

Merged
merged 1 commit into from
Nov 11, 2015

Conversation

ddragosd
Copy link
Member

This is a NON-BREAKING change. The old API still works, but the new one is executed first. If the API-KEY hasn't been defined in the new format ( as JSON ), it would read the old format ( individual Redis fields ).

In the old format all the fields associated with an API-KEY were stored using HMSET i.e.

HMSET cachedkey:$key:$service_id service-id $service_id

In the new format we're using the same Redis Key but we're storing the metadata into a new field called metadata, using HSET. This field stores a JSON string.

Since both HSET and HMSET are working on the same Redis Key the new implementation is additive and non breaking, as it simply adds a new field to the existing hash. If HGET cachedkey:$key:$service_id metadata returns the JSON, its value is used, else the API-KEY validator will try to do an HMGET on the other fields.

@alexpopero
Copy link
Contributor

@ddascal 🐑 it and deploy the new docker image in the public registry.

@wysedyqmy
Copy link

👍

1 similar comment
@cristianconstantin
Copy link
Contributor

👍

ddragosd added a commit that referenced this pull request Nov 11, 2015
Make api-key data more generic in order to attach more info to it
@ddragosd ddragosd merged commit 612fedf into master Nov 11, 2015
@ddragosd ddragosd deleted the issue-2 branch November 11, 2015 13:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants