feat: Inline render icloud image links

[stahnma]

Previously, we had icloud links as just links, but often times they are pictures. This change allows for images to render inline or use an opengraph preview if it's an album.

[Copilot]

Pull request overview

This PR adds inline rendering support for iCloud shared photo links. Previously, iCloud links were displayed as plain text links, but now they are enhanced to show images inline for single photos or rich preview cards for albums using OpenGraph metadata.

Key Changes:

• Detects iCloud photo links and fetches their HTML content to extract image URLs or OpenGraph metadata
• Renders single photos inline using extracted image URLs from Apple's page structure
• Displays album previews with images, titles, and descriptions using OpenGraph tags

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The og_image URL from external content is directly embedded into HTML without sanitization, creating an XSS vulnerability. An attacker could craft a malicious iCloud page with JavaScript in the og:image meta tag. The URL should be HTML-escaped before being inserted into the img src attribute.

[Copilot]

The og_title variable from external content is directly embedded into HTML without escaping, creating an XSS vulnerability. An attacker could inject malicious JavaScript through the og:title meta tag. The value should be HTML-escaped before being inserted into the alt attribute.

[Copilot]

The 'use' statement should be placed at the top of the file with other module imports, not inside a conditional block. Placing it here means it's compiled every time this code path is executed, which is inefficient. Move this to the top of the file with the other use statements.

[Copilot]

When the HTTP request fails (is_success returns false), there's no error handling or fallback behavior. The code silently continues with the default link_filler, which could be confusing if the request fails for unexpected reasons. Consider logging errors or providing feedback about failed requests.

Suggested change

	}
	}
	} else {
	# Log HTTP failures when attempting to fetch Apple Photos content
	warn "Failed to fetch Apple Photos URL '$apple_photos_url': " . $response->status_line;

[Copilot]

The regex patterns for extracting OpenGraph meta tags are fragile and may fail with variations in HTML formatting such as different quote styles, attribute ordering, or whitespace. Consider using an HTML parser like HTML::Parser or Mojo::DOM for more robust HTML parsing instead of regex-based extraction.

[Copilot]

Inline CSS styles are hardcoded throughout the preview card HTML, making it difficult to maintain consistent styling and impossible to update via CSS without modifying code. Consider using CSS classes instead of inline styles for better maintainability and separation of concerns.

Suggested change

	my $preview_html = '<div style="border: 1px solid #ddd; border-radius: 4px; padding: 10px; max-width: 500px; background: #f9f9f9;">';
	if ($og_image) {
	$preview_html .= '<img src="' . $og_image . '" style="max-width: 100%; height: auto; border-radius: 4px; margin-bottom: 8px;" alt="' . ($og_title || 'Apple Photos album') . '">';
	}
	if ($og_title) {
	$preview_html .= '<div style="font-weight: bold; margin-bottom: 4px;">' . $og_title . '</div>';
	}
	if ($og_description) {
	$preview_html .= '<div style="font-size: 0.9em; color: #666;">' . $og_description . '</div>';
	my $preview_html = '<div class="preview-card">';
	if ($og_image) {
	$preview_html .= '<img src="' . $og_image . '" class="preview-card-image" alt="' . ($og_title || 'Apple Photos album') . '">';
	}
	if ($og_title) {
	$preview_html .= '<div class="preview-card-title">' . $og_title . '</div>';
	}
	if ($og_description) {
	$preview_html .= '<div class="preview-card-description">' . $og_description . '</div>';

[Copilot]

The regex patterns for extracting image URLs from HTML and JSON are fragile and may fail with formatting variations or changes to Apple's page structure. Consider using proper HTML and JSON parsers (HTML::Parser and JSON module) for more robust and reliable extraction.

[Copilot]

Values such as og_image, og_title, and og_description are extracted from remote HTML and concatenated directly into $preview_html and then into $content without any HTML escaping or sanitization. Because the upstream page is fetched from a URL that can be attacker-controlled (see the Apple Photos URL handling above), an attacker can craft OpenGraph tags like <meta property="og:title" content=""><script>...</script"> so that malicious HTML/JavaScript is injected into your page, resulting in stored XSS for all viewers. Treat these fields as untrusted: HTML-encode or otherwise sanitize them before including in your markup, or only insert them into contexts where the templating layer escapes by default and avoid concatenating raw HTML strings from remote pages.

[Copilot]

The HTTP client is created with ssl_opts => { verify_hostname => 0 }, which disables TLS hostname verification for Apple Photos fetches. This means the certificate’s hostname is not checked against the requested host, weakening HTTPS and enabling certain man-in-the-middle scenarios where an attacker with a valid certificate for another domain can intercept and supply malicious HTML that your application will trust and render. Avoid turning off hostname verification; instead rely on the default certificate and hostname checks or address specific certificate issues with a more targeted trust configuration.

Suggested change

ssl_opts => { verify_hostname => 0 },

[Copilot]

This block treats any url containing icloud.com/photos and icloudlinks as an Apple Photos URL and passes it directly to LWP::UserAgent->get via apple_photos_url, without validating the actual scheme/host. An attacker can craft a URL like http://169.254.169.254/icloud.com/photos/.../icloudlinks or https://attacker.example/icloud.com/photos/.../icloudlinks so it matches the regex, causing the server to make arbitrary HTTP(S) requests to internal or attacker-controlled services (SSRF) and process the returned HTML. To prevent SSRF, strictly parse and validate the URL (e.g., enforce https scheme, require an exact host like www.icloud.com, and reject IP literals and internal hosts) before issuing the request, or derive the fetch URL from a trusted base plus a validated identifier rather than using the full user-supplied URL.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 9 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

This large block of Apple Photos handling code (over 80 lines) significantly increases the complexity of the displayTumble function. Consider extracting this into a separate helper method like 'handle_apple_photos_link' to improve readability and make the code more testable and maintainable.

[Copilot]

While the inline comments are helpful, this new feature lacks high-level documentation. Consider adding a POD (Plain Old Documentation) section to document the Apple Photos inline rendering feature, including its behavior, limitations (e.g., requires network access, may slow page loads), and how it interacts with the nsfw/otd filtering.

[Copilot]

Fetching external content synchronously during page rendering can significantly impact performance and user experience. Each iCloud link will add at least the timeout duration (5 seconds) to the page load time if the request fails, and potentially 1-2 seconds even on success. Consider implementing caching of the fetched image URLs or using asynchronous processing to avoid blocking page renders.

[Copilot]

The elsif condition can potentially conflict with the Twitter handling logic below (line 227). If a URL is both an iCloud image link and a Twitter URL, or if the Twitter block overrides the Apple Photos result, this could lead to unexpected behavior. Consider the order of these conditions and whether they should be mutually exclusive.

Suggested change

	if ($data->{$item}->{'url'} =~ /twitter/) {
	elsif (!$is_apple_photos && $data->{$item}->{'url'} =~ /twitter/) {

[Copilot]

The regex patterns used for extracting OpenGraph tags and image URLs are fragile and may break if the HTML structure changes or contains variations in formatting (e.g., single vs. double quotes, attribute ordering, whitespace). Consider using a proper HTML parser like HTML::TreeBuilder or Mojo::DOM instead of regex for more robust and maintainable HTML parsing.

[Copilot]

Inline CSS styles make the HTML harder to maintain and can lead to inconsistent styling across the application. Consider moving these styles to a CSS class or reusing existing styles from the application's stylesheet. This would improve maintainability and allow for easier theme changes.

[Copilot]

The LWP::Simple module is imported but never used in the Apple Photos feature code. It appears to only be used later in the Twitter handling block. Consider moving this import closer to where it's used or removing it from the top-level imports if it was only needed for Twitter handling.

[Copilot]

$data->{$item}->{'url'} is concatenated directly into an <img src="..."> attribute without any HTML escaping, so a crafted URL like http://example.com" onerror="alert(1) will produce <img src="http://example.com" onerror="alert(1)"> and execute arbitrary JavaScript in visitors' browsers. Because url ultimately comes from user-supplied input (via irclink/index.cgi), this is a straightforward, remotely exploitable XSS vector. You should HTML-escape or otherwise safely encode url before embedding it into the src attribute, and apply the same protection wherever other <img src="..."> tags are built from untrusted URLs.

Suggested change

	$link_filler = '<img src="' . $data->{$item}->{'url'} . '">';
	my $safe_url = encode_entities($data->{$item}->{'url'}, q{"&<>});
	$link_filler = '<img src="' . $safe_url . '">';

[Copilot]

$apple_photos_url is taken directly from $data->{$item}->{'url'} and only checked with the loose regex /icloud\.com\/photos.*icloudlinks/i, which does not actually restrict the hostname (e.g., http://127.0.0.1/icloud.com/photos/x/icloudlinks will pass). This allows an attacker who can submit links to point url at arbitrary internal or external hosts while still matching the regex, causing the server to issue HTTP(S) requests to attacker-chosen endpoints (SSRF). You should strongly constrain the Apple Photos URL (e.g., validate the scheme and host against an allowlist such as https://www.icloud.com) and avoid issuing backend requests to URLs that are not definitively trusted.

[stahnma]

Apple Photos opengraph previews suck. Noping out.