Add a mock grpc-web-proxy
#536
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Fewer demands on the environments, better managed, should make it simpler to use.
It turns out we were accessing the external `$PATH` which may or may not contain a valid `lightningd`.`
`uv` gives us more control, and fewer failure opportunities, so let's use it.
This proxy is used in the local testing environment to provide node-access to browser based clients. It strips the transport authentication, and replaces it with the payload authentication already used for the signer context.
We create a standalone service and front it with the grpc-web-proxy. Since the proxy must not rely on the payload to make decisions we just implemented a simple test proto just for this case.
cdecker
force-pushed
the
202444-grpc-web
branch
2 times, most recently
from
752c668
to
8719ebc
Compare
Besides the grpc-web proxy functionality, the node grpc-web-proxy also needs the capability of locating and starting a node if it hasn't been started yet. It also needs to be configured with the correct client certificates. The `NodeHandler` class encapsulates that logic. We also test it by running a `GetInfo` call through the grpc-web-client, the node-grpc-web-proxy-, finally hitting the node, and back again.
cdecker
force-pushed
the
202444-grpc-web
branch
from
8719ebc
to
851cf70
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We are working on building a
grpc-web-proxyfor production, but inthe meantime this already allows browsers and other environments that
do not like mTLS for authentication to integrate with Greenlight.
It exposes a
grpc-webinterface on the public side, allowingnon-mTLS clients to talk to it, and it can be provisioned with a valid
wildcard certificate, so browsers don't complain. On the other side it
forwards the requests over an mTLS connection to the actual node, such
that nodes continue to be protected from a variety of attacks.
Authentication and authorization is not affected, since the payloads
of the calls is signed by the device certificate, which is the one
that is ultimately the principal for authorization in the Runes. This
means that clients still need to implement the payload signing, but
that's much simpler than teaching browsers to not show scary messages
due to a self-signed cert or missing client cert.
sequenceDiagram alt grpc-web / TLS Browser->>Proxy: Please execute this request end Proxy-->>Proxy: Verify signature alt grpc-h2 / mTLS Proxy-->>Proxy: Fetch node client certificate Proxy-->>Node: Forward request Node-->>Node: Process request Node-->>Proxy: Response end alt grpc-web Proxy-->>Browser: Response end