Portal

The portal is the human-facing half of Kartis: a server-rendered web surface mounted at /portal/... inside the kartis-scan binary, next to the bearer-token /v1/... API that Eon Center, Eon Aethis and Eon Insights use. It is off by default — an existing deployment that only serves machine callers keeps exactly the surface it had. Turn it on in kartis-scan.yaml (see Configuration).

No npm, no build step: html/template with go:embed, htmx vendored in third_party/htmx/, one hand-written stylesheet, and charts as server-generated inline SVG.

Tenancy

Both surfaces resolve to the same tenant boundary before any query runs:

kartis-scan
├── /v1/*      bearer token   machine callers: Eon Center, Eon Insights
└── /portal/*  cookie session humans
                    │
                    └── both resolve to requested_by

A portal session resolves to the same requested_by value the API tokens already carry, rather than introducing a second scoping path. Eon Center’s tokens keep requested_by IS NULL and stay cross-customer callers.

Pages

Hosts and Attack surface answer different questions. Hosts shows what has been scanned; Attack surface shows what exists and answers, read from the recon pass’s liveness data. The same estate can therefore look thin on one page and hold thousands of hosts on the other.

Comparing two runs keys each kind of change on what makes it meaningful:

Login and sessions

The one-time code carries a code and nothing else — no findings, no host names, no customer name in the subject, so a misdelivered message discloses only that the address has a Kartis account. If SMTP submission fails the login returns a generic error and the failure is written to the audit table; the code is never shown in the response as a fallback, under any configuration.

A login depends on mail arriving, so treat deliverability as part of the deployment: SPF authorising the sending path, DKIM signing on the sender address with DMARC aligned, and a dedicated transactional sender.

Domain verification

Per root domain, the customer publishes:

_kartis-verify.<apex>.  TXT  "kartis-verify=<token>"

The scheduler refuses to run against an unverified domain. The record is re-checked monthly: one that disappears means the customer no longer controls the domain.

Domains found by org expansion can’t be furnished with a TXT record by definition — they’re the ones the customer had forgotten. Two classes resolve that:

An observed domain renders with an add to scope action, which triggers a fresh verification.

Scheduled runs

kartis-scheduler is a separate binary that only needs the database — it doesn’t scan, doesn’t talk to Redis and serves no HTTP. On each tick it picks up sessions whose next slot has passed and inserts a pending run; the existing claim chain does the rest.

Cadence is monthly or biweekly plus an anchor (day of month, or weekday), computed in Go — there is no cron expression to get wrong. The next slot is materialised, so the portal can show next scan on 1 October without recomputing it.

Four rules worth knowing before you operate it:

1. A failed scheduled run is not retried automatically. The portal shows the failure; the customer restarts it.
2. Runs missed during downtime are caught up once, not once per missed slot.
3. On-demand quota is debited when a run completes, so a failed run costs the customer nothing.
4. Exceeding the host limit does not truncate the run. Everything is stored and the overage is recorded — a scan that silently stopped at host 501 would produce a report that lies.

Deployment

The portal is HTTPS-only by construction: its session cookie carries the __Host- prefix and the Secure flag, which a browser rejects over plain HTTP. Run it behind your own TLS front and set trusted_proxies to that proxy, so forwarded client addresses and the forwarded scheme are believed from it and nowhere else. deploy/nginx/kartis.conf in the source repository is a working reference: one public vhost carrying /portal/ and nothing else, with /v1/* deliberately absent from it.

The insecure option drops the cookie prefix and the Secure flag. It exists for a test over plain HTTP and for nothing else.