Issue with Image Access for CiviCRM {contact.image_URL} Token due to Bot Blocking in Nginx Configuration

[cmastro-ixiam]

Hi Omega team,

We're currently experiencing an issue with image URLs generated via the {contact.image_URL} token in CiviCRM. These URLs point to the public route:

/civicrm/contact/imagefile?photo=filename.jpg

This route is handled by CRM_Contact_Page_ImageFile and is intentionally public, allowing image display in emails and external platforms (e.g., Gmail, Outlook). However, when these images are loaded by Google or other email clients (which often proxy image loads through their own bots), the access is being denied.

Problem When these images are included in emails, Gmail wraps them in a Google-hosted proxy URL like this: https://ci3.googleusercontent.com/meips/ADKq_NY63ZdwhDEUCPOPqlGCG_BrkclbWcihCSN903Jwyu8kezKouf2EhJD-D-rxyvO6vhn-cna2K8FARpc5rvmbwzpMVGA6CvC0P6t0k-U-_ngBCYOZ20wLLEbYwFsdkPCZ4ox40NWcTi8I42MPw4=s0-d-e1-ft#https://URL/civicrm/contact/imagefile?photo=filename.jpg

This link ultimately resolves to our server’s image endpoint, but is fetched using a User-Agent that includes google or similar.

When performing the following request:

curl -A "google" -I https://URL/civicrm/contact/imagefile?photo=filename.jpg

The response is:

HTTP/1.1 403 Forbidden
Server: nginx
Date: Mon, 02 Jun 2025 09:11:31 GMT
Content-Type: text/html
Content-Length: 146
Connection: keep-alive
Vary: Accept-Encoding
X-Frame-Options: SAMEORIGIN

This appears to be caused by bot blocking directives in your Nginx configuration. For example, in the following file:

• https://github.com/omega8cc/provision/blob/5.x-lts/http/Provision/Config/Nginx/server.tpl.php#L284

We found:

###
### Deny all known bots/spiders on some URIs.
###
map $http_user_agent $is_bot {
  default  '';
  ~*crawl|bot|spider|tracker|click|parser|google|yahoo|yandex|baidu|bing  is_bot;
}

###
### Deny almost all crawlers under high load.
###
map $http_user_agent $deny_on_high_load {
  default  '';
  ~*crawl|spider|tracker|click|parser|google|yahoo|yandex|baidu|bing  deny_on_high_load;
}

This configuration results in legitimate image requests by Google or Gmail being blocked, preventing images from loading in email clients that rely on proxy image fetchers.

Expected Behavior

These images should be accessible without authentication and regardless of the user agent, as their purpose is to be publicly visible in emails and similar unauthenticated contexts.

Request Would it be possible to exempt the /civicrm/contact/imagefile route from bot-based blocking in the Nginx configuration? Ideally, we’d like to allow image fetching from this path regardless of the user-agent.

Let us know if you need further technical details or logs from our side.

Thanks in advance for your support.

Best regards, Crisitan.

[GValFr35]

You can add a custom Nginx location block in nginx_vhost_include.conf to override the default behavior.

location /civicrm/contact/imagefile {
    expires       30d;
    tcp_nodelay   off;
    access_log    off;
    log_not_found off;
    add_header  Access-Control-Allow-Origin *;
    try_files   $uri @drupal;
}

Related doc: https://github.com/omega8cc/boa/blob/5.x-dev/docs/REWRITES.md

[omega8cc]

This has been fixed in https://github.com/omega8cc/provision/commit/2fedc20a4c230418eaf485982fc3df022a981995

To apply either edit your /data/disk/oX/config/includes/nginx_vhost_common.conf (patch may not work) or run self-upgrade as explained in the docs at https://github.com/omega8cc/boa/blob/5.x-lts/docs/SELFUPGRADE.md

[omega8cc]

Note that this may need further improvements/exceptions since we basically remove any protection on these URLs and this may open a window for effective DoS-like attacks -- even by aggressive crawlers because we also don't use Nginx microcaching there.