Repository navigation
Drive Telegram authentication and subscriptions through the browser - #2228
Conversation
size-limit report 📦
|
fbdd684 to
40cadcd
Compare
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #2228 +/- ##
==========================================
+ Coverage 73.83% 73.98% +0.14%
==========================================
Files 129 129
Lines 3727 3736 +9
Branches 860 865 +5
==========================================
+ Hits 2752 2764 +12
+ Misses 969 966 -3
Partials 6 6
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
e986793 to
dfaa780
Compare
|
tags are cut, so the pins can become released versions: one more thing while you are in there: #2232 is merged, and rest of the PR reads fine to me. |
Telegram is the one auth provider whose flow leaves the browser: the reader messages a bot, and no page can reach that. e2e/telegramstub answers as the bot API for the four calls the flow makes and takes the reader's side of the exchange through /control/send, so the round trip becomes drivable end to end. It runs on its own instance, because adding a provider to the main one would change the auth panel every other case reads. Reaching it needs the bot API base url to be settable, which is what --telegram.api-url adds. It serves a real operator need beyond the tests, a proxy or a self-hosted Bot API server where Telegram is blocked, and both consumers honour it: the auth provider and the notification service. The value is an origin, and the token travels in the request path, so it has to be a host the operator controls. Writing the coverage found two defects in the wiring. An instance with telegram auth enabled and notifications failing registered the provider and never started anything to listen, so it accepted the configuration and stayed permanently deaf. And a nil *notify.Telegram was assigned into an interface, where it is not nil, so the guard downstream let it through. The subscription panel needed three fixes of its own. Resubscribing set the step back without requesting a new token, so the panel offered a link built from one the backend had already discarded. A failure stayed on screen after the next call succeeded, because neither the check nor the unsubscribe cleared it. And the message had nowhere to render outside the initial step, so a failure in the other two was silent. The settable API base reaches the notification service through go-pkgz/notify v1.5.0 and the auth provider through go-pkgz/auth v2.3.0, both released. compose-e2e-coverage.yml gains the Telegram instance. coverage.sh takes the services it must see a profile from, and the directories it merges, from that file alone, so an instance present only in the base stack is skipped and the run still reports success on a total that quietly omits it.
dfaa780 to
a66bc17
Compare
|
Both pins are the released tags now, and the branch is rebased onto master.
|
Telegram is the one authentication provider whose flow leaves the browser: the reader messages a bot, and no page can reach that. This makes the round trip drivable end to end, for both authentication and notification subscriptions.
backend/go.modcarries the releasedgo-pkgz/notifyv1.5.0 andgo-pkgz/authv2.3.0, both of which ship the settable bot API base this needs.The fixture
e2e/telegramstubanswers as the bot API for the four calls the flow makes, and takes the reader's side of the exchange through/control/send, which is the step inside Telegram that a browser cannot perform. It runs on its own instance, because adding an auth provider to the main one would change the auth panel every other case reads.The setting it needs
Reaching a stub means the bot API base URL has to be settable, which is what
--telegram.api-urladds. It serves a real operator need beyond the tests: a proxy or a self-hosted Bot API server, in places where Telegram is blocked. Both consumers honour it, the auth provider and the notification service. The value is an origin, and the bot token travels in the request path, so it has to be a host the operator controls.Two defects the coverage found
An instance with Telegram authentication enabled and notifications failing registered the provider and then started nothing to listen with, so it accepted the configuration and stayed permanently deaf to it. And a nil
*notify.Telegramwas assigned into an interface, where it is not nil, so the guard downstream let it through.What it adds to backend coverage
Measured with the e2e coverage reporting from #2232: the full browser suite run against an instrumented stack, once on #2232 alone and once with this change on top, so the only difference is this branch and its two Telegram tests.
37.9% to 40.4% of backend statements, +142 newly covered.
The 32 extra statements in the denominator are this branch's own production code, so the gain is not an artefact of measuring less.
app/providersapp/notifyapp/rest/apiapp/cmdapp/store/serviceapp/store/engineapp/providersis the one worth pointing at. It holds a single function,DispatchTelegramUpdates, and nothing else in the suite reaches it: it was the only package at exactly 0% across the whole e2e run. The two defects above are covered rather than only fixed, at 83.3% formakeTelegramAuthand 64.7% forstartTelegramAuthAndNotify.