[Bug]: Link preview image blocked by content security policy

[paramazo]

⚠️ This issue respects the following points: ⚠️

• [X] This is a bug, not a question or a configuration/webserver/proxy issue.
• [X] This issue is not already reported on Github (I've searched it).
• [X] Nextcloud Server is up to date. See Maintenance and Release Schedule for supported versions.
• [X] Nextcloud Server is running on 64bit capable CPU, PHP and OS.
• [X] I agree to follow Nextcloud's Code of Conduct.

Bug description

Some users access the nextcloud via IPv4 and some via Domain. If those users are sharing links in Nextcloud Talk, the preview gets blocked by the browser cause of browsers content security policy.

Steps to reproduce

1. Browse your nextcloud via IPv4 and with Domainname
2. Share some Links in Nextcloud Talk with a preview image generated
3. Check if the preview image is displayed correctly

Expected behavior

The preview image should be linked with the same base url as the user is accessing nextcloud with.

Installation method

Official All-in-One appliance

Operating system

Debian/Ubuntu

PHP engine version

PHP 7.4

Web server

Apache (supported)

Database engine version

None

Is this bug present after an update or on a fresh install?

None

Are you using the Nextcloud Server Encryption module?

None

What user-backends are you using?

• [ ] Default user-backend (database)
• [X] LDAP/ Active Directory
• [ ] SSO - SAML
• [ ] Other

Configuration report

No response

List of activated Apps

- activity: 2.17.0
  - bruteforcesettings: 2.5.0
  - calendar: 4.2.1
  - circles: 25.0.0
  - cloud_federation_api: 1.8.0
  - comments: 1.15.0
  - contacts: 5.0.2
  - contactsinteraction: 1.6.0
  - dashboard: 7.5.0
  - dav: 1.24.0
  - deck: 1.8.3
  - drawio: 2.0.2
  - federatedfilesharing: 1.15.0
  - federation: 1.15.0
  - files: 1.20.1
  - files_external: 1.17.0
  - files_lock: 24.0.1
  - files_pdfviewer: 2.6.0
  - files_rightclick: 1.4.0
  - files_sharing: 1.17.0
  - files_trashbin: 1.15.0
  - files_versions: 1.18.0
  - firstrunwizard: 2.14.0
  - forms: 3.0.3
  - groupfolders: 13.1.0
  - logreader: 2.10.0
  - lookup_server_connector: 1.13.0
  - mail: 2.2.2
  - nextcloud_announcements: 1.14.0
  - notes: 4.6.0
  - notifications: 2.13.1
  - oauth2: 1.13.0
  - onlyoffice: 7.6.8
  - password_policy: 1.15.0
  - photos: 2.0.1
  - privacy: 1.9.0
  - provisioning_api: 1.15.0
  - recommendations: 1.4.0
  - related_resources: 1.0.4
  - serverinfo: 1.15.0
  - settings: 1.7.0
  - spreed: 15.0.2
  - systemtags: 1.15.0
  - text: 3.6.0
  - theming: 2.0.1
  - twofactor_backupcodes: 1.14.0
  - twofactor_totp: 7.0.0
  - updatenotification: 1.15.0
  - user_ldap: 1.15.0
  - user_status: 1.5.0
  - viewer: 1.9.0
  - weather_status: 1.5.0
  - workflowengine: 2.7.0
Disabled:
  - admin_audit
  - encryption
  - sharebymail: 1.10.0
  - support: 1.3.0
  - survey_client: 1.8.0
  - suspicious_login

Nextcloud Signing status

No response

Nextcloud Logs

No response

Additional info

No response

[szaimen]

Hi, which nc version?

[paramazo]

Hi, which nc version?

Nextcloud was recently updated to v25.0.3 which introduced this new Feature in Nextcloud Talk.

[solracsf]

@nickvergessen is this a Talk thing?

[nickvergessen]

Browser log is not there, so can't judge. But I think it's not a Talk thing, as the feature exists without Talk as well for Text and other apps and also the previews are served by the Nextcloud server. So I would assume it's a problem with the nextcloud server config, but that was not shared.

[paramazo]

As mentioned the browser is refusing to load the image because of the Content Security Policy if nextcloud is used via IPv4:

Here the exact browser console output:

Refused to load the image '<URL>' because it violates the following Content Security Policy directive: "img-src 'self' data: blob: <URL>".

I can not find any config in config.php to solve this behaviour. This config does not fix it:

'trusted_domains' =>
array (
  0 => 'machine.domainname.de',
  1 => '192.168.0.150',
  2 => 'machine',
)

// Profile pictures does work, cause they are referenced with relative paths. It would be great if Talk Chat would also use relative links.

// index.php/apps/photos are using relative path as img src and it works.

So i assume it is indeed a Talk thing, maybe some other apps too

[joshtrichards]

Hi @paramazo -

I can't reproduce this and I suspect this is a configuration issue. We really need the full report template filled out to confirm this a bug. Having it in the initial report saves both us and you time going back and forth.

What are your overwrite* parameters? I suspect you have overwritehost set because that's the primary way I can reproduce this behavior (and it's expected in that situation).

[paramazo]

Thanks for your response @joshtrichards. I have rechecked the config and found the overwrite.cli.url set to my fqdn. Anyway, the behaviour makes no sense to me.

[joshtrichards]

I have rechecked the config and found the overwrite.cli.url set to my fqdn.

Yes, but is the fqdn prefixed by http or with https?[1] And how does that compare to each of the below access methods you're using?

Some users access the nextcloud via IPv4 and some via Domain

If you're mixing how you access Nextcloud you're going to have a problem, particularly if you don't take some extra steps.[2]

You might have some luck integrating overwritecond.[3]

[1] https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/config_sample_php_parameters.html#overwrite-cli-url

[2] https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/config_sample_php_parameters.html#proxy-configurations

[3] https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/reverse_proxy_configuration.html

[nextcloud-command]

This issue has been automatically marked as stale because it has not had recent activity and seems to be missing some essential information. It will be closed if no further activity occurs. Thank you for your contributions.