Hi, I’ve seen DAML json-api uses hardcoded value secret for decoding the payload. how do I use the custom secret instead of the default?
1 Like
When using a shared secret, you should use it to sign the JWT. How this happens, depends largely on the language and libraries that you are using.
Note that in general you don’t have to use an hard-coded secret; when starting the sandbox, if you want the Ledger API (and the JSON API) to be secured, you are advised to use one of the several options to use an asymmetric key pair (as described here on the documentation).
2 Likes
Yeah I saw that. but I was wondering if it was possible just to change the JWT decoding secret
1 Like
Yes, you can, it’s documented in the warning note on the page I linked.
--auth-jwt-hs256-unsafe=<secret>. The sandbox will expect all tokens to be signed with HMAC256 with the given plaintext secret.
1 Like
The JSON API does not have any secret. It just passes on the token to the Sandbox without verifying it. So there is no change necessary on the JSON API. You just need to change the sandbox secret as @stefanobaghino-da explained.
1 Like
okay. but when I am starting the daml json api instance… I am not running any daml sandbox, I suppose the daml sandbox runs in back ground?
my daml ledger is deployed on canton. so I am just connecting the daml json-api to the ledger port of my participant node. in this situation where shoud I make required changes?
1 Like
I am not sure if canton supports authentication atm. By default it runs without any authentication so the secret you use is not relevant and will be ignored.
2 Likes
Canton doesn’t yet support JWT decoding, i.e. the authService is hard-coded to AuthServiceWildcard which is an AuthService that authorizes all calls by always returning a wildcard [[Claims]]
Or let’s put it this way. The code is available, it can just not be configured and is therefore not exposed yet, but it will be in one of the next releases.
3 Likes
yup. you are right I just tested this.
1 Like