Content Security Policy Breaks Pasword Reset

ℹ️ Support
1
Support intro

Sorry to hear you’re facing problems :slightly_frowning_face:

help.nextcloud.com is for home/non-enterprise users. If you’re running a business, paid support can be accessed via portal.nextcloud.com where we can ensure your business keeps running smoothly.

In order to help you as quickly as possible, before clicking Create Topic please provide as much of the below as you can. Feel free to use a pastebin service for logs, otherwise either indent short log examples with four spaces:

example

Or for longer, use three backticks above and below the code snippet:

longer
example
here

Some or all of the below information will be requested if it isn’t supplied; for fastest response please provide as much as you can :heart:

Nextcloud version (eg, 12.0.2): 17.0.0
Operating system and version (eg, Ubuntu 17.04): Docker 19.03.4 on Ubuntu 18.04
Apache or nginx version (eg, Apache 2.4.25): I don’t know I’m sorry.
PHP version (eg, 7.1): 7.3.10

The issue you are facing:
If a user attempts to reset their password, they get a network error when entering in a new password. The console says

Content Security Policy: The page’s settings blocked the loading of a resource at http://cloud.domain.tld/lostpassword/set/<some letters and numbers>/user (“connect-src”).

Is this the first time you’ve seen this error? (Y/N): Y

Steps to replicate it:

  1. Click “forgot password” when attempting to log in
  2. Click the link sent to your email
  3. Enter in a new password.

The output of your Nextcloud log in Admin > Logging:

Nothing relevant.

The output of your config.php file in /path/to/nextcloud (make sure you remove any identifiable information!):

<?php
$CONFIG = array (
  'htaccess.RewriteBase' => '/',
  'memcache.local' => '\\OC\\Memcache\\APCu',
  'apps_paths' => 
  array (
    0 => 
    array (
      'path' => '/var/www/html/apps',
      'url' => '/apps',
      'writable' => false,
    ),
    1 => 
    array (
      'path' => '/var/www/html/custom_apps',
      'url' => '/custom_apps',
      'writable' => true,
    ),
  ),
  'instanceid' => '[id]',
  'passwordsalt' => '[password]',
  'secret' => '[secret]',
  'trusted_domains' => 
  array (
    0 => 'cloud.domain.tld',
  ),
  'datadirectory' => '/var/www/html/data',
  'dbtype' => 'pgsql',
  'version' => '17.0.0.9',
  'overwrite.cli.url' => 'http://cloud.domain.tld',
  'dbname' => 'nextcloud',
  'dbhost' => 'db',
  'dbport' => '',
  'dbtableprefix' => '',
  'dbuser' => 'oc_root',
  'dbpassword' => '<password>',
  'installed' => true,
  'maintenance' => false,
  'mail_smtpmode' => 'smtp',
  'mail_sendmailmode' => 'smtp',
  'updater.release.channel' => 'stable',
  'loglevel' => 2,
  'twofactor_enforced' => 'false',
  'twofactor_enforced_groups' => 
  array (
    0 => 'admin',
  ),
  'twofactor_enforced_excluded_groups' => 
  array (
  ),
  'theme' => '',
  'mail_from_address' => 'NOREPLY',
  'mail_smtpauthtype' => 'LOGIN',
  'mail_smtphost' => 'ims.domain.tld',
  'mail_smtpport' => '587',
  'mail_domain' => 'ims.domain.tld',
  'mail_smtpauth' => 1,
  'mail_smtpname' => 'noreply@ims.domain.tld',
  'mail_smtppassword' => '[password]',
  'mail_smtpsecure' => 'tls',
  'updater.secret' => '[secret]',
);

The output of your Apache/nginx/system log in /var/log/____:

I’m very professional.

lrwxrwxrwx 1 www-data www-data   11 Oct 17 14:28 access.log -> /dev/stdout
lrwxrwxrwx 1 www-data www-data   11 Oct 17 14:28 error.log -> /dev/stderr
lrwxrwxrwx 1 www-data www-data   11 Oct 17 14:28 other_vhosts_access.log -> /dev/stdout
2

@whit-colm Hi Whit! Welcome and I appreciate how you have redacted sensitive information in your report.

FYI

Apparently, you provide a listing of files only but no ‘output’ i.e. content from the log files involved. You should make access to the access.log and error.log log files and look for entries with timestamps around the time the a.m. issue was reported, I presume.

You may have a look at the ‘more’ (command) if you do not feel familiar with the above.

After the applicable consideration you could seek to improve this report and in addition could copy some appropriate excerpt from the log files into this forum if you feel this would be reasonable.

Hope this helps.

3

Ok so I’m a clown, the issue has been fixed. I was running it through traefik and hadn’t set it up right. For reference, my solution was to change the /config/config.php file to say:

  [...]
  'overwrite.cli.url' => 'https://cloud.domain.tld',
  'overwriteprotocol' => 'https',
  [...]

Then it works fine.

4

@whit-colm Fine with me and good effort. :+1: