(WIP) Cache delete endpoint #51
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
return cache response json return none, log output
log cache status use standard js datetimeoptions type
remove trailing slash
use waitUntil on load and update change error code change production type to accurately reflect what it is change PRODUCTION comparison to be more explicit reverse conditional url order revert change log production variable log url origin
remove url origin log
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Pulling this out of #50 since there might be some additional concerns with exposing an endpoint that gives access to our cache.
This would allow the worker to access the cache from the pages side, allowing the worker to invalidate a cache from a different data center. Haven't tested if this would actually work yet. (Which I should probably do before actually considering the rest of this lol)
However, there are two concerns:
===operator in javascript terminates early if the string deviates earlier in number of letters from the secret key. In addition to this, if this gets implemented, it may be good to private this repo so outside people don't know the header used to share the auth/api key.Been thinking about a way to compare letter by letter manually to prevent a timing attack. Or maybe computing a hash so the user input and secret key have the same length. Or maybe it's not that big of a deal anyway lol, worst thing that happens is the cache gets invalidated.
These considerations do take up more time though so I'm breaking this out into its own thing.