Description
Hi!
First of all, thanks a lot for this skeleton.
I'm trying to make async updates work with Mercure, allowing only authenticated updates and subscribers - however there's some things I do not understand yet.
In the docker-compose.yml at line 26 we see the following configuration:
MERCURE_JWT_SECRET: ${CADDY_MERCURE_JWT_SECRET:-!ChangeMe!}
which is the same value that is passed to Caddy on lines 36/37:
MERCURE_PUBLISHER_JWT_KEY: ${CADDY_MERCURE_JWT_SECRET:-!ChangeMe!}
MERCURE_SUBSCRIBER_JWT_KEY: ${CADDY_MERCURE_JWT_SECRET:-!ChangeMe!}
-
As they all share the same value (both the default value as well as whatever the user defines as
$CADDY_MERCURE_JWT_SECRET
) I take it that these values should be identical. -
It seems that the
MERCURE_JWT_SECRET
environment variable inside thephp
service relates to theMERCURE_JWT_SECRET
within.env
- which by default reads:
# The secret used to sign the JWTs
MERCURE_JWT_SECRET="!ChangeMe!"
So I would take it that these values should be cryptographically random values, which would be used as the secret passphrase to sign and verify JWTs.
However, the documentation for configuring Mercure within API Platform says the following:
MERCURE_JWT_SECRET
: a valid Mercure JSON Web Token (JWT) allowing API Platform to publish updates to the hub
The JWT must contain a mercure.publish property containing an array of topic selectors
which at least conflicts with the comment inside .env
, and if the rest of my understanding is correct, also conflicts with the configuration inside docker-compose.yml
.
So my question boils down to the following:
-
Should the
publisher_jwt
andsubscriber_jwt
values within the Caddyfile indeed contain a cryptographically random value? -
Should the
MERCURE_JWT_SECRET
within.env
indeed contain a JWT, which should be signed with the cryptographically randompublisher_jwt
value?
Activity
Jayfrown commentedon Dec 15, 2021
Seems related to this: #128
dunglas commentedon Dec 16, 2021
Indeed!
This is definitely outdated. This behavior changed in the recent versions of MercureBundle. It's now a secret key that must be set, not a full JWT.
As a summary:
CADDY_MERCURE_JWT_SECRET
allows setting the secret used by the hub,MERCURE_JWT_SECRET
is the one used by the bundleJayfrown commentedon Dec 16, 2021
Thanks for clarifying. I'm still a little confused on the following:
It seems that the
docker-compose.yml
configuration conflicts with this, as theCADDY_MERCURE_JWT_SECRET
ends up asMERCURE_PUBLISHER_JWT_KEY
/MERCURE_SUBSCRIBER_JWT_KEY
(used by the hub) as well asMERCURE_JWT_SECRET
(used by the bundle)So if the Mercure hub should have a different secret than the MercureBundle, then which secret holds which purpose? I had initially thought they should be the same secret, so that the hub can verify JWTs generated by the bundle.
dunglas commentedon Dec 16, 2021
Yes indeed you're right. I mean that you must pass
CADDY_MERCURE_JWT_SECRET
to set the proper env vars used by the bundle and by Caddy itself (it's not possible to use the same name everywhere because this would be a conflict).Jayfrown commentedon Dec 16, 2021
Ah!💡
I initially misunderstood what you meant when you said
"the same env var"
. I thought you meant it cannot be the same value.Thanks again for clearing this up!
minor #16293 [Mercure] Compatibility with the Docker integration and …