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
I think it makes sense that if rollup-boost is a middleware sidecar for proposer op-node/op-geth we can reuse the same JWT token we receive from proposer op-node to send the requests to proposer op-geth.
Then, the jwt-token flag would represent the jwt token between rollup-boost and builder op-geth.
The text was updated successfully, but these errors were encountered:
The problem here is that there is no way for HttpClient to proxy / access the headers of the incoming request to the server per request. The jwt token in the header is derived from the jwt secret + timestamp so it is different for every request.
The alternative would be to instantiate a new HttpClient at the middleware layer per request, since the headers are static when the client is instantiated. One workaround could be adding a set_header function without initiating a new client per request, but still wacky.
I think it makes sense that if
rollup-boost
is a middleware sidecar for proposer op-node/op-geth we can reuse the same JWT token we receive from proposer op-node to send the requests to proposer op-geth.Then, the
jwt-token
flag would represent the jwt token betweenrollup-boost
and builderop-geth
.The text was updated successfully, but these errors were encountered: