Repository navigation
https-app: an app can claim a handle ending, so its handles resolve through nginx - #3
Merged
Merged
Conversation
…hrough nginx An app that hands out handles of its own, as a PDS does, had no way to have them resolve: the leaf's *.<domain> covers one label, and nginx sent <x>.<ending>.<domain> to the alpha, which answered "User not found". A third word to https-app.sh claims an ending: nginx gets a server for *.<ending>.<domain> beside the app's upstream, Host passed through, and the leaf is reissued from the same CA with *.<ending>.<domain>. https-up.sh reissues the leaf whenever it lacks any name the scripts expect, and the leaf's names live in one place, https-lib.sh. The PDSes' own endings and an ending another app holds are refused.
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
An app that hands out handles of its own, as a PDS does, can now have them resolve on the https devnet.
Before: a handle like
bookclub.gh.devnet.testfailed twice. The leaf's*.devnet.testcovers one label, so TLS failed, and nginx sent the name to the alpha, which answered "User not found".Now:
scripts/https-app.sh <name> <port> <ending>claims an ending.*.<ending>.<domain>that proxies to the app with Host passed through, so the app answers/.well-known/atproto-did. As the longer wildcard, it wins over the alpha's*.<domain>.*.<ending>.<domain>, so nothing has to be trusted again. A reload picks it up.alpha,regularandprodare refused, and so is an ending another app holds. A rerun without the ending drops it.https-lib.sh(leaf_names).https-up.shreissues the leaf whenever it lacks any of them, which covers the old*.devnet.internalcheck.The two-word form is unchanged, and so is every existing
data/https/appsline.Checked
regular, an uppercase ending and a fourth word.devnet-spaces) with the group host claiminggh: an existing group's handle now resolves to its DID through nginx, and alice's still resolves on the alpha. The group host's probes pass: day 2 8/8, including a new check that a fresh group's handle resolves through nginx with the certificate verified, day 3 8/8, day 4 16/16 and sign-up 4/4. atmo's groups e2e against the host passed 52 of 52.DEVNET_DOMAIN=lighthouse.snowglobe.test(on 127.0.0.2, beside the lab) with a second host: the leaf got*.gh.lighthouse.snowglobe.test, the host's handle domain was.gh.lighthouse.snowglobe.test, and the probes passed day 2 8/8 (the group's handle resolved there), day 3 8/8 and sign-up 4/4. Day 4 was 15/16: one part of f8 asks to join a lab group by its fixed DID, which that copy's directory doesn't have. The copy was torn down afterward.