nineap
d22cd0de41
Bot buttons that open a Web App (Личный Кабинет/Тарифы/Синдикат) appeared to load and then silently do nothing on the dev stand. Root cause: teloxide's WebAppInfo::url (and the underlying Bot API) requires an HTTPS URL — Telegram's client refuses to render a Web App served over plain HTTP, with no error surfaced to the user, just a stuck loading state. WEB_APP_BASE_URL was http://dev.netrunner-vpn.com:8080. Port 443 on the dev VPS is already in use by a VPN node, and port 80 is closed, so a normal HTTP-01 ACME challenge won't work. Added a custom Caddy build (caddy-dns/cloudflare) terminating TLS via DNS-01 on port 8443 instead, reverse-proxying to the existing plain-HTTP app container. WEB_APP_BASE_URL and the CORS/CSRF allowlists now point at the :8443 origin, and COOKIE_SECURE reverts to true (the default, matching prod) — now that the backend actually has real TLS to serve it over, we no longer need the plain-HTTP workaround introduced for the earlier cookie-drop bug. Verified the custom image builds and the Caddyfile validates (only the dummy Cloudflare token used for the local test is rejected, as expected). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
10 lines
508 B
Docker
10 lines
508 B
Docker
# syntax=docker/dockerfile:1
|
|
# Кастомная сборка Caddy с DNS-провайдером Cloudflare — нужна для DNS-01
|
|
# ACME challenge на dev VPS, где порты 80/443 недоступны/заняты (443 —
|
|
# VPN-нодой, 80 закрыт). DNS-01 не требует открытых входящих 80/443 вообще.
|
|
FROM caddy:2-builder AS builder
|
|
RUN xcaddy build --with github.com/caddy-dns/cloudflare
|
|
|
|
FROM caddy:2
|
|
COPY --from=builder /usr/bin/caddy /usr/bin/caddy
|