Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug]: Security & setup warnings when Nextcloud is in subdirectory (e.g., webserver is not set up to serve .js.map files, Could not check for JavaScript support via any of your trusted_domains nor overwrite.cli.url.) #47950

Closed
4 of 8 tasks
c-prompt opened this issue Sep 13, 2024 · 3 comments · May be fixed by #47943
Labels
0. Needs triage Pending check for reproducibility or if it fits our roadmap 29-feedback bug feature: settings

Comments

@c-prompt
Copy link

c-prompt commented Sep 13, 2024

⚠️ This issue respects the following points: ⚠️

Bug description

Not withstanding https://docs.nextcloud.com/server/latest/admin_manual/release_notes/upgrade_to_28.html#setup-checks, Nextcloud Hub 8 (29.0.7) is ignoring overwrite.cli.url being defined as a subdirectory when doing system and security checks. I receive the following errors because my installation is in a subdirectory (e.g., nextcloud.mydomain.com/nextcloud_dir):

There are some warnings regarding your setup.

    Your webserver is not set up to serve `.js.map` files. Without these files, JavaScript Source Maps won't function properly, making it more challenging to troubleshoot and debug any issues that may arise.
    Could not check for JavaScript support via any of your `trusted_domains` nor `overwrite.cli.url`. This may be the result of a server-side DNS mismatch or outbound firewall rule. Please check manually if your webserver serves `.mjs` files using the JavaScript MIME type. To allow this check to run you have to make sure that your webserver can connect to itself. Therefor it must be able to resolve and connect to at least one its `trusted_domains` or the `overwrite.cli.url`.
    5 errors in the logs since September 6, 2024, 2:40:39 PM
    Could not check that your web server serves security headers correctly, unable to query `/nextcloud_dir/index.php/heartbeat` For more details see the documentation ↗.

    `check_for_working_wellknown_setup` is set to false in your configuration, so this check was skipped.
    Could not check for WOFF2 loading support. Please check manually if your webserver serves `.woff2` files. To allow this check to run you have to make sure that your webserver can connect to itself. Therefor it must be able to resolve and connect to at least one its `trusted_domains` or the `overwrite.cli.url`. For more details see the documentation.

See also many help requests at https://help.nextcloud.com/t/many-could-not-check-on-security-and-setup-warnings/201840/6.

UPDATE: I should clarify the root directory properly returns a 403 as intended:

root@my_ip ~ $ curl -H 'Cache-Control: no-cache, no-store' nextcloud.mydomain.com/      
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>403 Forbidden</title>
</head><body>
<h1>Forbidden</h1>
<p>You don't have permission to access this resource.</p>
</body></html>
root@my_ip ~ $ curl -H 'Cache-Control: no-cache, no-store' nextcloud.mydomain.com/nextcloud_dir
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>301 Moved Permanently</title>
</head><body>
<h1>Moved Permanently</h1>
<p>The document has moved <a href="http://nextcloud.mydomain.com/nextcloud_dir/">here</a>.</p>
</body></html>
root@my_ip ~ $ curl -H 'Cache-Control: no-cache, no-store' nextcloud.mydomain.com/nextcloud_dir/

UPDATE 2: I should also mention that updating /etc/hosts (per #44114 (comment)) to include:

127.0.0.1 nextcloud.mydomain.com

...responds with "It works" content but does not resolve the Nextcloud errors.

curl -H 'Cache-Control: no-cache, no-store' nextcloud.mydomain.com

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
    <title>Apache2 Debian Default Page: It works</title>
    <style type="text/css" media="screen">

Steps to reproduce

  1. Setup Nextcloud within subdirectory
  2. Upgrade to 29.0.7
  3. Check for system and security issues (https://nextcloud.mydomain.com/nextcloud_dir/index.php/settings/admin/overview)

Expected behavior

When checking for system and security issues (https://nextcloud.mydomain.com/nextcloud_dir/index.php/settings/admin/overview), Nextcloud should use/take into account that overwrite.cli.url is defined as a subdirectory.

Nextcloud Server version

29

Operating system

Debian/Ubuntu

PHP engine version

PHP 8.3

Web server

Apache (supported)

Database engine version

MySQL

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

Updated from a MINOR version (ex. 28.0.1 to 28.0.2)

Are you using the Nextcloud Server Encryption module?

None

What user-backends are you using?

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

Configuration report

No response

List of activated Apps

No response

Nextcloud Signing status

No response

Nextcloud Logs

No response

Additional info

No response

@c-prompt c-prompt added 0. Needs triage Pending check for reproducibility or if it fits our roadmap bug labels Sep 13, 2024
@joshtrichards
Copy link
Member

joshtrichards commented Sep 13, 2024

I believe #46255 should have helped with this by prioritizing overwrite.cli.url, but I haven't tested it myself. Though it's in 29.0.7 so I guess maybe not.

@solracsf
Copy link
Member

More likely this PR will fix it: #47883 (v29.0.8)

@solracsf solracsf linked a pull request Sep 14, 2024 that will close this issue
2 tasks
@susnux
Copy link
Contributor

susnux commented Sep 14, 2024

Duplicate of #47880

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
0. Needs triage Pending check for reproducibility or if it fits our roadmap 29-feedback bug feature: settings
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants