SimpleCacheDecorator and providesPerItemTtl leads undocumented behaviors about laminas-cache HOT 6 CLOSED

I just ran into this and it took a surprising amount of head scratching before I realised the per item TTL was to blame. Commenting mostly so I can keep track of this issue.

Originally posted by @Zegnat at zendframework/zend-cache#171 (comment)

from laminas-cache.

@dol @Zegnat It might be fixed in #184 and released yday - can you please check version 2.8.3 and tell me if you still observe the issue?

Thanks!

Originally posted by @michalbundyra at zendframework/zend-cache#171 (comment)

from laminas-cache.

PSR-16

... If the underlying implementation does not support TTL, the user-specified TTL MUST be silently ignored. ...

I have the feeling that what PSR-16 defines here could be very very dangerous:
Here a simple example that will result in a security issue:

function verifyAccessToken($accessToken) {
    $accessTokenValidKey = 'access_token_valid_' . md5($accessToken);
    if ($cache->get($accessTokenValidKey) !== '1') {
        // verify access token by querying authentication server
        // if invalid -> return false
        // if valid -> authentication server returns expiration ($expiresIn)
        $cache->set($accessTokenValidKey, '1', $expiresIn);
    }
    return true;
}

The Time-to-Live should define the maximum time where this item is considered valid. In caching it normally means that there is a guaranty to be invalidated after that time and this guaranty gets lost here.

Originally posted by @marc-mabe at zendframework/zend-cache#171 (comment)

from laminas-cache.

Closing this as there were no author updates since 06/2018.

from laminas-cache.

@dol If this is still a thing, feel free ping me here so I can re-open the issue.

from laminas-cache.

@boesing Will do. Thank you. Switched programming language and company in the meantime. I leave it here for my former team members.

from laminas-cache.