Commit Graph

10 Commits

Author SHA1 Message Date
Oliver Gugger
648fb22f63
multi: wrap all errors 2024-04-11 15:04:03 +02:00
ffranr
cd566eb097
multi: fix fmt.Errorf error wrapping
Refactor fmt.Errorf usage to correctly wrap errors instead of using
non-wrapping format verbs.
2024-02-27 11:13:40 +00:00
Oliver Gugger
55b53555e9
multi: improve readability of goroutine defers
This commit fixes the readability of some of the defer calls in
goroutines by making sure the defer stands out properly.
2022-11-21 13:54:24 +01:00
Oliver Gugger
b1d8767a0c
rpcperms: intercept errors too 2022-07-14 09:36:50 +02:00
Oliver Gugger
86c64abfe6
rpcperms: allow requests to be replaced as well
With this commit we allow a replacement message to be sent by the
middleware for a request type as well as the response type. This allows
an incoming RPC request to be modified before it is forwarded to lnd.
2022-07-14 09:36:36 +02:00
Oliver Gugger
dc32ca61f8
rpcperms: add replaceProtoMsg
Because of the way the gRPC Receive() method is designed, we need a way
to replace a proto message with the content of another one without
replacing the original instance itself (e.g. overwrite all values in the
existing struct instance).
2022-07-14 09:36:36 +02:00
Carsten Otto
50ec39477e rpcperms: fix typo [skip ci] 2022-04-04 22:58:41 +02:00
Oliver Gugger
54a25146f4
rpcperms: add unique request ID
This commit adds a unique request ID that is the same for each gRPC
request and response intercept message or each request/response message
of a gRPC stream.
2021-11-08 15:01:26 +01:00
Oliver Gugger
9a28a4a9ff
lnrpc+rpcperms+lntest: add unique MW message ID
This commit adds a new unique intercept message ID that is different for
each message sent to an RPC middleware. This will allow us to re-purpose
the existing request ID field into its original intention, which was to
have a unique ID for a full gRPC request/response pair or gRPC stream as
a whole.
2021-11-08 15:00:29 +01:00
Oliver Gugger
75ca574790
lnrpc+rpcperms: add middleware handler
With this commit we introduce the concept of RPC middleware: A mechanism
similar to the existing channel or HTLC interceptors but this time for
gRPC messages themselves.
An RPC middleware can register itself to the main RPC server to get
notified each time a new gRPC request comes in, a gRPC response is sent
back or a streaming RPC is connected. The middleware can
validate/inspect incoming requests and modify/overwrite outgoing
responses.

Since this also opens the door for malicious software to interfere with
lnd in a negative way, we bind everything to macaroons with custom
caveat conditions: A middleware declares upon registration which custom
caveat name it can handle. Only client requests that send a macaroon
with that custom caveat will then be given to the middleware for
inspection. The only exception is if the middleware instead registers
to use the read-only mode. In that mode it will be able to intercept
all requests/responses, even those not made with a special encumbered
macaroon. But the middleware won't be able to alter responses in the
read-only mode. Therefore requests with the default, unencumbered macaroons
can never be modified by any middleware.
2021-09-20 13:12:49 +02:00