You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There is a pattern that is increasing code entropy quite a bit: every struct field is configurable through an environment variable (following the 12-factor App manifesto)
We are currently however at a case where we need to mint jwt tokens outside Reva and the same configuration leaks to outside services. The most recent example is seen here. The problem in turn is this line:
EnvVars: []string{"WOPISERVER_REVA_GATEWAY"},
Similar other extensions define their own names for what it essentially is the same value (that is, if run in the same vm):
Proposed solutions
Adopt the same name for all services that need to know about the reva gateway address.
Make better use the service registry to fetch the address of the reva gateway.
Agree on a naming scheme (i.e: let extensions define their EXTENSION_REVA_GATEWAY_ADDR variables and add REVA_GATEWAY as a fallback to configure all extensions at one, similar to OCIS_URL).
There is a pattern that is increasing code entropy quite a bit: every struct field is configurable through an environment variable (following the 12-factor App manifesto)
We are currently however at a case where we need to mint jwt tokens outside Reva and the same configuration leaks to outside services. The most recent example is seen here. The problem in turn is this line:
Similar other extensions define their own names for what it essentially is the same value (that is, if run in the same vm):
Proposed solutions
EXTENSION_REVA_GATEWAY_ADDR
variables and addREVA_GATEWAY
as a fallback to configure all extensions at one, similar toOCIS_URL
).For more context, see:
The text was updated successfully, but these errors were encountered: