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

Create function to compute surrogate key of a giturl. #123

Closed
tripodsan opened this issue Jun 18, 2019 · 2 comments · Fixed by #125
Closed

Create function to compute surrogate key of a giturl. #123

tripodsan opened this issue Jun 18, 2019 · 2 comments · Fixed by #125
Assignees
Labels

Comments

@tripodsan
Copy link
Contributor

tripodsan commented Jun 18, 2019

for cache invalidation, we need a common function to compute a surrogate key from a github resource.

related:

As mentioned in adobe/helix-publish#108 (comment), the key should also be computable in VCL.

Suggest

  • as input use the canonical giturl of the resource:
    https://github.com/<owner>/<repo>.git<path>#ref
  • as key use helix
  • compute the hmac_sha256 with key and input using the sha256 algorithm.
  • encode the result using base64.
  • this function is also available in fastly, with digest.hmac_sha256_base64
@trieloff
Copy link
Contributor

Also note that there is a maximum length in Fastly for the Surrogate-Key header, so we should truncate the hash. I'd rather have a few accidental purges due to hash collisions over missed purges due to dropped keys.

@tripodsan tripodsan self-assigned this Jun 19, 2019
adobe-bot pushed a commit that referenced this issue Jun 20, 2019
# [1.5.0](v1.4.0...v1.5.0) (2019-06-20)

### Features

* **utils:** Add function to calculate surrogate key ([d4aae86](d4aae86)), closes [#123](#123)
@adobe-bot
Copy link

🎉 This issue has been resolved in version 1.5.0 🎉

The release is available on:

Your semantic-release bot 📦🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants