Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

First payment from a present-but-unregistered client is refused (client-not-registered) — extend the renewal presence-proof to first purchases

Aperta
  • Qualcosa non va?
#582 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@Amperstrand ci sta già lavorando.

Dal 7/10/2026.

  • #737 di @Amperstrand — aperta

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
48/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
go
Ambito
backend-api-design, payments

Direzione di ricerca

Start in src/merchant/merchant.go at PurchaseSession, then read sessionIsRenewal, clientRegisteredForGate, and grantSessionAccess to understand the existing presence and rollback behavior. Check the related tests, if present, before changing the pre-Receive registration check. Done means a resolvable client can make a first purchase without NDS registration, unresolved clients remain rejected, and genuine access-grant failures still roll back.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Summary

A payment submitted by a client that is present and identifiable but not registered in NoDogSplash is refused before Receive with client-not-registered. The renewal path already treats "this MAC just submitted a token" as proof of presence and proceeds (the valve's bounded auth retry re-registers, grantSessionAccess rolls back on true failure) — but a first purchase from the same kind of client is hard-refused. Proposal: extend that same presence-proof to first purchases.

Observed

Lab rig, tollgate-wrt v0.6.0-alpha4 on OpenWrt 24.10.8. A wired LAN-side client (management host on br-lan) POSTs a valid token directly to the merchant:

$ curl -X POST --data "$TOKEN" http://192.168.103.51:2121/
{"kind":21023,...,"tags":[["level","error"],["code","client-not-registered"],
 ["p","14:5a:fc:49:c2:23"]],
 "content":"No captive-portal session found for this device. Reconnect to the TollGate Wi-Fi and try again.",...}

Note the MAC was resolved just-in-time from the socket (ARP table — "p" tag carries it), the mint is reachable, and the token is left unspent. The recovery instruction is wrong for this client class: it is wired, and no amount of reconnecting produces an NDS registration.

Mechanism

src/merchant/merchant.go, PurchaseSession pre-flight:

if !m.sessionIsRenewal(macAddress) && !m.clientRegisteredForGate(macAddress) {
    // refused: client-not-registered, before Receive (#403 L1)
}
  • clientRegisteredForGate probes ndsctl (3 attempts) and fails open on probe errors — only a clean "not registered" verdict refuses.
  • sessionIsRenewal (known MAC with active/expired local session) bypasses the check entirely, with an explicit comment: the client "is demonstrably present (it just submitted a token through the captive-portal) and the valve's bounded auth retry is what re-registers it", accepting the deliberate residual risk that Receive succeeded but the gate cannot open (rolled back by grantSessionAccess).

Why this bites beyond the lab

For a Wi-Fi customer loading the portal this is nearly unreachable (portal load = NDS pre-auth registration). The refusal hits:

  1. Wired/LAN-side clients — no NDS interception ever registers them; the error's advice is a dead end.
  2. Direct API/wallet payments that POST a token without rendering the portal page (automation, headless clients, the ?token= TIP-03 flow if the page load is skipped).
  3. Lapsed NDS state between portal load and payment submission (self-heals today only via reconnect).

Proposal

Treat "MAC resolved from the request socket + payment POST received" as the presence-proof for first purchases too — the same evidence the renewal path already accepts — and let the existing valve auth retry perform the just-in-time registration, with the existing grantSessionAccess rollback covering genuine registration failure:

  • Unresolvable/sentinel MACs stay rejected (already covered by the device-unresolved class — no change).
  • The pre-Receive order stays intact; only the registration precondition is relaxed from "NDS knows this MAC" to "this device is demonstrably present".
  • At minimum, fix the notice text for non-Wi-Fi clients ("Reconnect to the TollGate Wi-Fi" → guidance that matches the client class).

Reproduction

  1. Router with tollgate-wrt running, a reachable mint in accepted_mints.
  2. From a wired host on br-lan (so its MAC lands in the ARP table but never in NDS): curl -X POST --data "$CASHU_TOKEN" http://<router>:2121/
  3. Observe the kind-21023 client-not-registered event; wallet balance unchanged.

Concrete consumer: the physical rig's phone-payment E2E and host-side payment automation currently need a real Wi-Fi client solely to satisfy this pre-flight.

Lingua principale
Go
Stelle
12
Fork
14
Merge medio
1g 6h
PR unite (30g)
211

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di OpenTollGate/tollgate-module-basic-go

Tutte le issue di OpenTollGate/tollgate-module-basic-go

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.