Skip to content

Route channel logos through /api/image-proxy to fix mixed content over HTTPS - #132

Open
EasterwoodBiker wants to merge 1 commit into
ardoviniandrea:mainfrom
EasterwoodBiker:feature/proxy-channel-logos
Open

EasterwoodBiker wants to merge 1 commit into
ardoviniandrea:mainfrom
EasterwoodBiker:feature/proxy-channel-logos

Conversation

@EasterwoodBiker

Copy link
Copy Markdown

Problem

When ViniPlay is served over HTTPS (e.g. behind a reverse proxy that terminates TLS), live-channel logos fail to load and every channel shows a ? placeholder. Provider tvg-logo URLs are almost always plain http://, and the browser blocks them as mixed content on an HTTPS page. VOD posters are unaffected because they already go through the server-side image proxy.

Fix

Live-channel logos were rendered directly from the raw tvg-logo URL in the guide list, search results, multi-view, program notifications and the admin stream-history table. This routes them through the existing GET /api/image-proxy endpoint (whose own comment says it exists "to avoid mixed content warnings"), the same way VOD posters already work, via a shared utils.proxiedImageUrl() helper. The inline VOD logic is refactored to use the same helper so there is a single source of truth.

  • Relative / data / empty URLs pass through unchanged.
  • Chromecast metadata images (cast.js) are intentionally left direct, since the cast device — not the browser — fetches them, and a relative proxy URL would not resolve there.

No new endpoint or dependency; reuses the image proxy that already ships.

🤖 Generated with Claude Code

…r HTTPS

Live-channel logos (guide list, search results, multiview, program
notifications, admin stream history) were rendered directly from their provider
tvg-logo URL, which is almost always plain http://. When ViniPlay is served over
HTTPS behind a reverse proxy, the browser blocks those images as mixed content
and every channel shows a "?" placeholder.

VOD posters already avoided this by routing through the existing /api/image-proxy
endpoint. This applies the same treatment to channel logos via a shared
utils.proxiedImageUrl() helper, and refactors the inline VOD logic to use it so
there is a single source of truth. Relative/data/empty URLs pass through
unchanged; Chromecast metadata images (cast.js) are intentionally left direct
since the cast device, not the browser, fetches them.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant