Details
-
Bug
-
Resolution: Cannot Reproduce
-
High
-
None
-
3.3.0
Description
It's not possible to set up Varnish invalidation token using an environmental variable.
Setup:
Project configured to use Varnish, Varnish running in the background
Steps to reproduce:
1. Set up project to use Varnish token invalidation:
export HTTPCACHE_VARNISH_INVALIDATE_TOKEN=testToken
2. Replace the public/index.php file with the one from metarepository: https://github.com/ezsystems/ezplatform/blob/master/public/index.php (this is a workaround for https://issues.ibexa.co/browse/EZP-32277 and can be omitted if that one is fixed)
3. Clear Varnish cache running
php bin/console fos:httpcache:invalidate:tag ez-all -vv
Expected:
Cache is cleared
Actual:
08:25:17 CRITICAL [app] 405 error response "Method not allowed" from caching proxy ["exception" => FOS\HttpCache\Exception\ProxyResponseException^ { …}] In HttpDispatcher.php line 138: [FOS\HttpCache\Exception\ExceptionCollection] 405 error response "Method not allowed" from caching proxy
This is coming from the VCL, meaning that the tokens don't match:
https://github.com/ezsystems/ezplatform-http-cache/blob/master/docs/varnish/vcl/varnish5.vcl#L176-L178
Varnishlog entries for the token request:
* << BeReq >> 3
- Begin bereq 2 fetch
- Timestamp Start: 1610439959.295549 0.000000 0.000000
- BereqMethod PURGEKEYS
- BereqURL /_ez_http_invalidatetoken
- BereqProtocol HTTP/1.1
- BereqHeader Host: 192.168.33.16
- BereqHeader User-Agent: GuzzleHttp/6.5.5 curl/7.71.1 PHP/7.4.9
- BereqHeader xkey-softpurge: ez-all
- BereqHeader X-Invalidate-Token: testToken
- BereqHeader X-Forwarded-For: 192.168.33.1
- BereqHeader Surrogate-Capability: abc=ESI/1.0
- BereqHeader X-Forwarded-Port: 80
- BereqHeader accept: application/vnd.ezplatform.invalidate-token
- BereqHeader x-fos-token-url: /
- BereqHeader x-fos-token-method: PURGEKEYS
- BereqMethod GET
- BereqHeader Accept-Encoding: gzip
- BereqHeader X-Varnish: 3
- VCL_call BACKEND_FETCH
- VCL_return fetch
- BackendOpen 26 ezplatform 192.168.0.122 80 10.0.2.15 53056
- BackendStart 192.168.0.122 80
- Timestamp Bereq: 1610439959.296502 0.000953 0.000953
- Timestamp Beresp: 1610439959.384909 0.089360 0.088407
- BerespProtocol HTTP/1.1
- BerespStatus 200
- BerespReason OK
- BerespHeader Date: Tue, 12 Jan 2021 08:25:59 GMT
- BerespHeader Server: Apache/2.4.46 (Unix) PHP/7.4.9
- BerespHeader X-Powered-By: PHP/7.4.9
- BerespHeader Cache-Control: public, s-maxage=86400
- BerespHeader X-Invalidate-Token:
- BerespHeader Vary: Accept,cookie,authorization
- BerespHeader xkey: ez-all ez-invalidate-token
- BerespHeader X-Powered-By: Ibexa Open Source v3
- BerespHeader Content-Length: 0
- BerespHeader Content-Type: application/vnd.ezplatform.invalidate-token
Looks like the returned token from the backend is an empty string, not what has been set by the env variable.
If I set the token value explicitly for a SiteAccess:
system:
default:
# Cache pool service, needs to be different per repository (database) on multi repository install.
cache_service_name: '%cache_pool%'
# These reflect the current installers, complete installation before you change them. For changing var_dir
# it is recommended to install clean, then change setting before you start adding binary content, otherwise you'll
# need to manually modify your database data to reflect this to avoid exceptions.
var_dir: var/site
content:
# As we by default enable EzSystemsPlatformHttpCacheBundle which is designed to expire all affected cache
# on changes, and as error / redirects now have separate ttl, we easier allow ttl to be greatly increased
default_ttl: '%httpcache_default_ttl%'
# HttpCache purge server(s) setting, eg Varnish, for when ezpublish.http_cache.purge_type is set to 'varnish'.
http_cache:
purge_servers: ['http://192.168.33.16']
varnish_invalidate_token: 'testToken'
then it behaves correctly