Warda-DNSDocs Warda: from ward — to protect, guardian
v0.7.5
Menu

Customer area

From 0.7.5. System → Customer area (administrators, area system; internal/admin/account.go, ui/src/components/CustomerArea.svelte) links this box to an account of the customer area of Warda, https://account.warda-dns.com (warda-portal), which then gives its plan in a statement signed for this box, renewed every day. Everything goes through the online service of Warda (warda-cloud): the box never calls the customer area itself, and nothing of the network is sent, only the key of the box.

  • Identity: the box is known by its key at the online service (its public Ed25519 key, base64url, 43 characters: Key of the box on the card), never by its name, address or identifier. The key goes with the backups (see Backups).
  • Link this box: the box asks a code (POST /v1/account/link of the online service): WL-XXXX-XXXX, valid 15 minutes, once, 10 a day by box; the card shows it with Copy and Open the customer area (https://account.warda-dns.com/link?code=WL-…); the customer types it under My boxes → Add a box and names the box. New code makes another. A box belongs to one account at most: to move it, unlink it first.
  • Unlink (confirmed): the box leaves its account (DELETE /v1/account/link); the statement kept is forgotten, the plan becomes free. The customer can also unlink it from the customer area.
  • The statement: the JSON of the plan (v, box_key, account, plan, users, sites, ha_peer, generation, issued, expires, beta) and its signature. The box checks the exact bytes received with the public keys of the customer area embedded in Warda (planKeys, several for a change of key), then v 1, a known plan, its own key in box_key, and expires in the future; it keeps the statement as received (checked again at each start). A statement lives 14 days.
  • The plan of GET /api/v1/subscription is the one of the last valid statement; without one (none, expired, unlinked) it is free. Beta unchanged: while the subscriptions are closed, every function stays open whatever the plan (see Plans).
  • Renewal (task plan, Plan from the customer area): 1 to 5 minutes after the start, then every 24 hours give or take an hour; Renew now asks at once (at most once a minute). It sends the generation of the statement held (0 without one), the key of the other box of a pair of high availability, and the version of Warda (POST /v1/plan). Answers: a new statement; linked: false (in no account: the statement is forgotten); 409 (below); anything else (the online service or the customer area not answering, 503) keeps the last statement and says why under Last renewal.
  • "The same key is used by another box" (409, state clone): another copy of this box renewed meanwhile (a copy of the box, or an old backup restored while the other runs); this one gets nothing until it is chosen. A backup restored on new hardware keeps the key but not the statement (it is not in the backups): it renews with the generation 0, which the customer area takes for a restore and serves; the old hardware, if it still runs, is then refused. When the box that must keep the plan is the refused one, the customer chooses Make this the box on its page in the customer area.
  • High availability: the two boxes of a pair tell each other their key at every synchronisation (ha.sync, see High availability), and each sends the key of the other with its renewal. The customer area validates the pair when both boxes are linked to the same Warda Business account and name each other (in the beta, a pair it would refuse is validated, flagged beta); the statement then names the peer, and the card says Pair validated with the other box (or that it names another box than the one paired here).
  • Not active yet in 0.7.5: the key of the customer area is not made yet, so planKeys is empty. Linking and unlinking work (to try the way through), but the box asks no statement, the task plan does not run, and the card says Plan statements are not active yet (state inactive): nothing changes, everything stays open. A later version of Warda carries the key.

The statement, its generation, the last renewal and the code are kept in the database of the box (meta account): not in the backups, and not given to the secondary of a pair — they belong to each box. The administration log records account.link and account.unlink.

APIs (administrators; reading needs the area system, the rest its change): GET /api/v1/account (available — the online service is set —, active — a key of the customer area is known —, state inactive/not_linked/linked/expired/clone, box_key, plan, issued, expires, generation, beta, ha_peer, ha_validated, renewed, tried, error, and code, code_expires, link_url while the code is valid, only for the accounts that change the system); POST /api/v1/account/link (a code); DELETE /api/v1/account/link (unlink); POST /api/v1/account/refresh (renew now; 409 the plan statements are not active yet, or asked less than a minute ago). 409 without the online service ("The online service of Warda is not set on this installation: the customer area needs it.") and when the customer area does not answer (the customer area is not available) or after 10 codes a day (too many codes asked today, try again tomorrow).