feat: add AutoTLS example #3103
Conversation
Co-authored-by: Marcin Rataj <[email protected]>
|
@MarcoPolo Is it a problem this PR upgrades the go to 1.23 in go.mod? I believe this happened due to dependency on p2p-forge |
|
ipshipyard/p2p-forge#29 should solve the build issue |
|
When running this, occasionally it doesn't retrieve (or even request). Here are logs |
this also passes correct logger so debug messages from p2p-forge/client are printed correctly
| // Configure CA ACME endpoint | ||
| // NOTE: | ||
| // This example uses Let's Encrypt staging CA (p2pforge.DefaultCATestEndpoint) | ||
| // which will not work correctly in browser, but is useful for initial testing. | ||
| // Production should use Let's Encrypt production CA (p2pforge.DefaultCAEndpoint). | ||
| p2pforge.WithCAEndpoint(p2pforge.DefaultCATestEndpoint), // test CA endpoint | ||
| // TODO: p2pforge.WithCAEndpoint(p2pforge.DefaultCAEndpoint), // production CA endpoint |
There was a problem hiding this comment.
@2color would appreciate sanity check on this.
My "strong conviction held weakly" is that we should be good citizens for LE and not use production endpoints in examples like this.
For now, I switched this code to use staging endpoint Let's Encrypt provided for the purpose of testing and examples – https://letsencrypt.org/docs/staging-environment/.
But since libp2p.direct is on https://publicsuffix.org/ we don't really care about rate-limiting, mostly just dont want to pollute https://crt.sh/?q=libp2p.direct with noise produced by this example.
At the same time, perhaps its a lesser evil to use production endpoint in example – if people copy&paste blindly, they will get broken certs and unless they try to connect to WSS in browser, they will not know its broken.
So the question is: should we switch this example back to production one? (p2pforge.DefaultCATestEndpoint → p2pforge.DefaultCAEndpoint)
There was a problem hiding this comment.
To be honest, I wasted a fair while trying to figure out what was wrong after I had deliberately switched to the staging env. I think we just need to log conspicuously when using staging.
There was a problem hiding this comment.
This is a good idea.
I will add the same "ERROR" log to p2p-forge/client when staging/testing endpoint is used to make sure folks remember to change it and it never sneaks into production.
This way we dont pollute this example, and everyone using client will benefit.
| go 1.23 | ||
|
|
||
| toolchain go1.22.3 | ||
| toolchain go1.23.3 |
There was a problem hiding this comment.
💭 I suspect this produces staticcheck ./... error:
In the past, the fix was to:
- check if
go install honnef.co/go/tools/cmd/staticcheck@latest→staticcheck ./...passes locally - ask IPDX to update Unified GO CI to use new staticcheck
There was a problem hiding this comment.
Confirmed, staticcheck@a093f7c2d3d45d5104fb3414ae939a98be37be02 used on CI does not support 1.23 correctly, and 1.22 is also bit out of date: https://github.com/dominikh/go-tools/releases
Will ping IPDX.
this implements idea from libp2p/go-libp2p#3103 (comment) to ensure users who set up staging endpoint for testing are always aware fo it and never ship it to production
This adds an example showing how to use the p2p-forge client library with the AutoTLS backend to issue a wild card certificate.
Credits to @guillaumemichel for writing the initial code in this example.
Fix before merging