Skip to content

Every map renders with CARTO's "API KEY REQUIRED" watermark — keyless legacy basemap URL, hardcoded in four bundles #842

Description

@hokiepokedad2

Every map in the DM Alerts site renders with a diagonal "API KEY REQUIRED — carto.com/basemaps/apikey" watermark across the tiles. Seen on the area picker's Jump to Region map at /areas on alerts.pogoalerts.net, but it is not specific to that page.

Cause

The app requests CARTO's legacy keyless basemap endpoint:

https://{s}.basemaps.cartocdn.com/light_all/{z}/{x}/{y}{r}.png

CARTO now requires a key on basemap requests and watermarks unkeyed ones. Note that it still answers HTTP 200 and still returns usable tiles — the only signal is the watermark drawn into the image, so this fails silently and will not show up in logs or a health check.

Scope

The URL is hardcoded in the built Angular output rather than configured. In the currently deployed image it appears in four separate chunks:

/app/wwwroot/chunk-XJ72AAWK.js
/app/wwwroot/chunk-PNN62S4T.js
/app/wwwroot/chunk-FQYOQ4CF.js
/app/wwwroot/chunk-DT72DDLJ.js

So this is not a one-line change at a single call site, and there is nowhere to set a key today without a rebuild.

Suggested direction

Make the tile URL and the key configurable rather than baked into the bundle, and have one place build the layer instead of four. PogoAlerts.Full solved the same problem with a small BasemapService that takes a config-driven URL template containing a {key} placeholder, URL-encodes the key into it, and exposes a single create() used by every map — which also gives you one place to handle the light/dark variants and to detect a missing key and say so.

Two things worth carrying over from doing it there:

  • The CARTO parameter is key, not api_key. The wrong name also returns 200 and also watermarks, so it is easy to "fix" this and change nothing.
  • Surface a missing key in the UI rather than letting it render a watermarked map, since a 200 response means nothing here.

Note on the key itself

This repository is public. The key belongs in deployment config or secrets, not in the repo or in this issue — see the PogoAlerts secrets convention (real values live in a gitignored .secrets/env.sh, docs carry a <vault: …> placeholder). Ask in #dev for the value.

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions