feat: implement HeritageImageController with proxyImage#477
Closed
zigzagdev wants to merge 6 commits into
Closed
Conversation
Fetches the UNESCO image URL from world_heritage_site_images via the Image model and streams the binary response back to the browser, bypassing CORS/CORP restrictions that block direct browser requests. Closes #471 Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Access-Control-Allow-Origin is already managed by HandleCors middleware via cors.php. Keeping it in the controller caused duplicate headers. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
WorldHeritageVm.id is the site ID, not the image record's PK. Querying by world_heritage_site_id with is_primary/sort_order ordering returns the primary image for the site, which is what the frontend passes. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
GET /api/v1/heritage-image/image/{imageId} fetches a single image by
its own PK, allowing the detail page to proxy each image in the
images[] array independently.
- /heritage-image/{siteId} → primary image (list page)
- /heritage-image/image/{imageId} → individual image by PK (detail page)
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Instead of proxying UNESCO /document/ URLs (blocked by Cloudflare as subresource requests), fetch main_video_url from data.unesco.org API on each request, extract the YouTube video ID, and return the YouTube hqdefault thumbnail binary. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Migration: add main_video_url column to world_heritage_sites - Command: world-heritage:sync-video-urls fetches main_video_url from data.unesco.org API and populates DB (1248 records synced) - Model: add main_video_url to WorldHeritage fillable - Controller: look up main_video_url from DB instead of calling UNESCO API on every request, then proxy YouTube hqdefault thumbnail Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Owner
Author
|
Closing: proxy approach not viable due to Cloudflare blocking server-side requests to UNESCO CDN. |
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
1 participant
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.
Summary
app/Packages/Features/Controller/HeritageImageController.phpproxyImagefetches the image URL fromworld_heritage_site_imagesvia theImageEloquent model, then streams the binary back to the browser404when no record exists for the givenid502when the upstream UNESCO request failsAccess-Control-Allow-Origin: *so the frontend can load images cross-originNo Domain layer needed
This is a pure infrastructure pass-through (DB lookup → HTTP fetch → stream response). There is no business logic, so no UseCase or Domain Entity is involved.
Verified
php artisan route:listinside Docker confirmsGET /api/v1/heritage-image/{id}resolves toHeritageImageController@proxyImage.Closes
#471
Part of
#475