Route channel logos through /api/image-proxy to fix mixed content over HTTPS - #132
Open
EasterwoodBiker wants to merge 1 commit into
Open
EasterwoodBiker wants to merge 1 commit into
EasterwoodBiker wants to merge 1 commit into
Conversation
…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.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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. Providertvg-logoURLs are almost always plainhttp://, 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-logoURL in the guide list, search results, multi-view, program notifications and the admin stream-history table. This routes them through the existingGET /api/image-proxyendpoint (whose own comment says it exists "to avoid mixed content warnings"), the same way VOD posters already work, via a sharedutils.proxiedImageUrl()helper. The inline VOD logic is refactored to use the same helper so there is a single source of truth.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