anxiousmodernman / co-chair Goto Github PK

Some examples of usage:
johanbrandhorst/grpcweb-boilerplate@0fa0da7

Not sure if co-chair does this but what about clustering using boltdb raft ?
That is how consul do it but since you want a very simple system you can just use one of the boltdb raft libraries.

A list of proxied backends is our main UI view. Every active proxy has a "delete" button. Clicking this button issues the correct grpc call to the backend, but in the UI only the last item is removed. We should remove the item corresponding to the button clicked.

Before clicking delete on "coleman":

After clicking delete:

After refresh:

We're just a tcp listener at our core. Test with some packet crafting tools to try and break things.

Examples:
http://sectools.org/tag/packet-crafters/
https://nmap.org/nsedoc/

We need to bundle compiled Typescript, CSS, and HTML into the golang binary with some modifications
to our build script.

There might be some changes in web.go to serve different assets, it's TBD.

Give prominent credit to all the awesome projects we depend on.

Now that we've switched to TypeScript, we need to wire up the front end to the backend.

How do we generate ts code from protobuf?

How do we call the backend from the TypeScript frontend?

See:
https://github.com/improbable-eng/grpc-web

Loaded in init:

Store = sessions.NewCookieStore([]byte("something-very-secret"))

Maybe randomness is a suitable default, as well. The worst that should happen is folks lose their session on restart. A bummer, but more secure than hardcoding something.

Tracking this PR: improbable-eng/grpc-web#137

When this (or similar) lands, we can deprecate uses of

import "github.com/johanbrandhorst/protobuf/wsproxy"

Very cool project and impressive use of lots of new stuff.

It says it proxies tcp, so does that mean that i can proxy a GRPC client server interaction, web sockets and maybe even udp stuff like QUIC ?

Current state:

We rely on API clients to send cert and key as []byte when adding a backend to the proxy. When we receive a connection, we look at the domain on the request and query the database to find the associated entry with the cert we require.

Problems:

1. If we had a wildcard cert for several subdomains, we'd have to duplicate the data in the database. For example, for domains one.example.com and two.example.com, they would both need duplicate bytes for a valid *.example.com wildcard cert.
2. We don't provide a magical option for LetsEncrypt

Our goal is to do what Caddy does, which is to attempt to transparently provide https via letsencrypt if a path to a cert and key are not provided.

We'll also want to:

• separate the storage of x509 certs and keys from other backend metadata, so that it is easier to cache and re-used certs and keys.
• Always check the cache first, not just for existence, but for the validity/expiration of a cert. Hit Let's Encrypt's API as little as possible in other words.