Cache Key Validation

[MGatner]

Description
Cache keys are currently a free-for-all, though the specification is much tighter than that. Additionally, some handlers have limits on the length of key that can be used. So far the only one I know for sure is FileHandler, because using too long of a key fails to create the file since it is invalid in the filesystem.

This PR adds cache key validation and hashing to address the above issues. Note that I am not a cache expert, so if someone with more knowledge or experience wants to chime in I would be grateful. For example, the restricted characters were based on PSR-6 but some handlers may actually allow broader key usage than that.

Checklist:

• Securely signed commits
• Component(s) with PHPdocs
• Unit testing, with >80% coverage
• User guide updated
• Conforms to style guide

[MGatner]

Thanks for the review @paulbalandan. I'd like your feedback on my responses before I implement any changes.

[MGatner]

@paulbalandan Go to my fork and select the psr-cache branch and that will give you an idea of what I'm working towards. This is part of a much bigger project to supply adapters for most PSR components that we don't supply natively. In this case, I am working on a project at my day job that uses a package which requires a PSR-6 implementation; currently I have to include an external cache library to make this work, even though we have a very healthy cache layer.

[paulbalandan]

PHP_INT_MAX is an excessively long amount. Can we have a reasonable number here?

[MGatner]

It's basically meant to be "unlimited". I couldn't find limits for all the handlers, but P/Redis stores the keys as binary strings with a limit of 512 MB - huge, in other words: https://stackoverflow.com/questions/5606106/what-is-the-maximum-value-size-you-can-store-in-redis

I'm open to other suggestions, or varying the specific handlers more, but that's how I got there.

[paulbalandan]

While I do not have a problem with proper code attribution, should this @see be addressed to the PSR-6 document instead? This gives me a false impression that Symfony Cache is the authoritative source for the list of reserved cache characters whereas PSR-6 clearly gives this out.

Key - A string of at least one character that uniquely identifies a cached item. Implementing libraries MUST support keys consisting of the characters A-Z, a-z, 0-9, _, and . in any order in UTF-8 encoding and a length of up to 64 characters. Implementing libraries MAY support additional characters and encodings or longer lengths, but must support at least that minimum. Libraries are responsible for their own escaping of key strings as appropriate, but MUST be able to return the original unmodified key string. The following characters are reserved for future extensions and MUST NOT be supported by implementing libraries: {}()/@:

[paulbalandan]

Just read this line: but MUST be able to return the original unmodified key string. Since MD5 hashing is a one-way process, then aren't we deviating again from PSR-6?

[MGatner]

That link is because I copied this code from Symfony, more of an attribution than a reference. Maybe I should remove the @see and just have the link?

BaseHandler::validateKey() is not trying to be PSR-6 compliant - we'd have bigger issues to address if that were the case. The PSR-6 adapter will use this but handle its own keys and exceptions.

[MGatner]

Test failures are unrelated:

55 Err:20 https://packages.microsoft.com/ubuntu/20.04/prod focal InRelease
56   Could not connect to packages.microsoft.com:443 (13.90.56.68), connection timed out [IP: 13.90.56.68 443]
57 Err:21 https://packages.microsoft.com/repos/azure-cli focal Release
58   Unable to connect to packages.microsoft.com:https: [IP: 13.90.56.68 443]
59 Reading package lists...
60 E: The repository 'https://packages.microsoft.com/repos/azure-cli focal Release' does not have a Release file.
61 Error: Process completed with exit code 100.

Any more thoughts on this one?

[paulbalandan]

I'm good with this, unless Lonnie has some more to add. 😁