3 Commits

Include renames

Author	SHA1	Message	Date
bobbanandClaude Sonnet 5	70ba60c7da	Add a phpIPAM import to the IP Addresses page ... New "Sync from phpIPAM" action on IP Addresses, alongside the existing "Sync from Tailscale" / "Sync from Proxmox" ones and built the same way: a new integration type (config in-app, URL + API app ID + app token, credentials encrypted at rest) that this page pulls from on demand. Deliberately import-only, not a full integration -- no dedicated page, dashboard widget, or nav entry, since that's all this was asked for. Auth is phpIPAM's static "App token" method: create an API app under Administration -> API with its security set to "SSL with App token", and its one-time code goes straight in as the `token` header (also sent as `phpipam-token`, in case a given version expects that name instead) -- no login call, no token to renew. The user/password "User token" method isn't implemented. Addresses are read the standard way: GET /subnets/, then GET /subnets/{id}/addresses/ for each, rather than assuming a single "all addresses" endpoint exists on every version. phpIPAM wraps every response as {code, success, data} -- including an empty result: a subnet with nothing in it answers success:false, message:"No addresses found" rather than success:true, data:[]. That's read as "nothing here", not a failure; anything else with success:false throws with phpIPAM's own message. One subnet failing outright (e.g. the app lacks permission on it) is skipped with a note rather than aborting the whole sync. Every address field is read defensively -- optional, independently type-checked -- so a field phpIPAM renames or drops in some version leaves that value blank instead of breaking the import. Imported entries: label from hostname or description, "phpIPAM" as vendor, the subnet's own description (or its CIDR, if it has none) as location, and description/note/MAC folded into notes. Existing sync plumbing (upsertSyncedEntry) gained a location parameter so this and any future sync can set it; the two existing syncs pass null, unchanged. Endpoints, the token header, and the address/subnet field names are cross-checked against phpIPAM's own published API documentation. Not verified against a live instance -- there wasn't one available while building this, so if a real sync comes back empty or with the wrong fields, that's the next thing to check. Verified with 23 backend checks against a fake phpIPAM server matching that documented shape (the empty-subnet quirk, a subnet that fails outright, malformed/missing fields, a non-JSON response) and the real route (added/updated/skipped counts, a manually-entered IP never overwritten, roles, no-enabled-integration, upstream failure surfaced per-integration rather than as a 500, audit entries) plus a browser check of the real IP Addresses page against the real routers: the sync button, its result message, re-syncing (updates rather than duplicates), the manual entry staying untouched, and the viewer view. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-29 19:49:10 +02:00
bobbanandClaude Sonnet 5	1a2dd19736	Add an Uptime Kuma integration: monitor status and which server each one watches ... New integration, following the existing pattern: config in-app (URL + API key, credentials encrypted at rest), its own Uptime Kuma page, an Integrations list entry, a Dashboard widget, and diagnostic-log/ integration-down-alert coverage for free via the shared withDiagLogging wrapper. Read-only -- no start/stop equivalent exists for a monitor. Uptime Kuma has no conventional REST API (the dashboard talks to it over Socket.IO); researched before writing any code, since guessing wrong here would have cost real time. The one machine-readable, authenticated endpoint that lists every monitor is its Prometheus exporter at GET /metrics, gated by HTTP Basic auth -- an API key as the password with the username left blank on current installs, or the real dashboard login on installs from before the API-key feature existed. This adapter authenticates the same way and parses that endpoint's text-exposition format itself (metrics: monitor_status, monitor_response_time, monitor_cert_days_remaining, monitor_uptime_ratio; labels: monitor_id, monitor_name, monitor_type, monitor_url, monitor_hostname, monitor_port), verified against the documented metric/label set and the actual upstream source (server/prometheus.js). A malformed line is skipped rather than failing the whole scrape. "What server is being monitored for what": each monitor's target (an IP for TCP checks, or the hostname out of the URL for HTTP/keyword checks) is matched against your servers' own IPs and hostnames -- reusing the same kind of match already used in the consistency report -- and linked to that server's page. Monitors with no single network target (groups, push monitors, DNS/keyword checks with a complex URL) are left unmatched rather than guessed at. Uptime Kuma's tags aren't read, since the Prometheus endpoint doesn't reliably distinguish a tag label from any other label it might add later. The username field is the first genuinely optional integration config field this app has had; IntegrationField gained an `optional` flag (server validation and both the add/edit web forms honor it) rather than special-casing Uptime Kuma. Verified with 48 backend checks (Prometheus text parsing including escaped quotes, decimals, negative numbers, and malformed lines; TCP vs. HTTP target/port extraction; every documented status code; server matching by IP, hostname, and short name, including no-match cases; the route's real HTTP round trip against a fake Uptime Kuma server, wrong credentials, upstream failures, roles, wrong/disabled/missing integration, diagnostic-log entries; the optional-field validation rule) and by driving the real page and the real Dashboard widget in a browser against the real routers, including CSV export and column sorting. Real dev database mtime untouched. Not verified: a real Uptime Kuma instance. Everything here was checked against Uptime Kuma's documented metric format, its actual upstream source, and a fake server built to match both -- not against a live installation. If your instance's /metrics output differs from what's documented (older version, unusual monitor types), the parser should degrade to an empty or partial monitor list rather than error, but that degradation itself hasn't been observed against the real thing. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-29 18:50:27 +02:00
bobbanandClaude Sonnet 5	ad6783b6a1	Extend badge color settings to cover integration types too ... Settings → DNS Badges only let you customize DNS provider badge colors. Expand it into a general Badges page with a second section for the six integration types (Tailscale, Proxmox, Synology, Semaphore, Gitea, Dockhand), applied to the type badge in the Manage integrations table. - New integrationColors key on AppSettings, stored/merged the same way as providerColors via the existing settingsStore. - New GET /api/settings/integration-colors — non-secret, any signed-in user, mirroring /provider-colors — so the badge color can be read without needing admin access to the full settings payload. - Renamed DnsBadgeSettings.tsx -> BadgeSettings.tsx (route /settings/dns-badges -> /settings/badges, sub-nav label "DNS Badges" -> "Badges") with both color sections saved together. Verified end-to-end against the real dev server: PUT persists integration colors independently of provider colors, the public integration-colors endpoint reflects updates immediately, and the change is audit-logged. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-15 21:28:26 +02:00