fix: add option to remove the webroot for setup checks and don't chec…

[kesselb]

• For [Bug]: NC29 .well-known URLs, failed on: /.well-known/caldav #45033

Summary

fix: add option to remove the webroot for setup checks and don't check trusted_domains.

1. The checks for well-known urls should always run against the root domain and therefore the option to remove the webroot.

2. For trusted domains, the available protocol is unknown, and thus some guesswork would be needed to make that work. I've decided for now to not consider them anymore to reduce false-positives.

TODO

• CI
• Review

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)

[susnux]

Not sure we had problems with false negative in the past because there are some configurations where the server is accessed e.g. by my-server.com but the machine can not resolve that domain or that is not its real domain but the proxy. So in that cases we iterate all trusted domains

[kesselb]

I've included an GitHub issue in the pull request.

It's also okay for me to keep the trusted_domains, it's just something I ran into while testing. The protcol is missing, and therefore the request goes to http:// which does not work on my dev setup because there is no http listener.

More important is the remove webroot part for installations in a subdirectory.

[MichaIng]

Since these tests are done from the backend, I'd test the CLI URL first (if not empty), i.e. add it as first entry to the array, since it should always work, and the urlGenerator one only if it differs as 2nd entry.

2. For trusted domains, the available protocol is unknown, and thus some guesswork would be needed to make that work. I've decided for now to not consider them anymore to reduce false-positives.

I am also not sure whether there are cases where the CLI URL is unset and the current client request domain is not accessible from the server. But you could add them as last array entries, to not increase false-positives. The test requests follow redirects. So without protocol, it should test HTTP first, which could even work when Nextcloud runs behind a HTTPS proxy, or otherwise follow the usually configured HTTPS redirect. That way we assure to not replace one regression with the tests with another one.
Since * is still a valid trusted domain entry, it should be probably removed/skipped.

EDIT: Read your last comment too late. Without HTTP listener or without HTTPS redirect it of course won't work, but it does not hurt to at least try them, if the other two did not succeed?

[come-nc]

Since these tests are done from the backend, I'd test the CLI URL first (if not empty), i.e. add it as first entry to the array, since it should always work, and the urlGenerator one only if it differs as 2nd entry.

2. For trusted domains, the available protocol is unknown, and thus some guesswork would be needed to make that work. I've decided for now to not consider them anymore to reduce false-positives.

I am also not sure whether there are cases where the CLI URL is unset and the current client request domain is not accessible from the server. But you could add them as last array entries, to not increase false-positives. The test requests follow redirects. So without protocol, it should test HTTP first, which could even work when Nextcloud runs behind a HTTPS proxy, or otherwise follow the usually configured HTTPS redirect. That way we assure to not replace one regression with the tests with another one. Since * is still a valid trusted domain entry, it should be probably removed/skipped.

EDIT: Read your last comment too late. Without HTTP listener or without HTTPS redirect it of course won't work, but it does not hurt to at least try them, if the other two did not succeed?

I agree with all this I think, overwrite cli first makes sense, then detected url, then trusted domains.

[come-nc]

/backport to stable30

[come-nc]

/backport to stable29

[come-nc]

/backport to stable28

[kesselb]

Thanks @come-nc for taking over, looks good to always try overwrite.cli.url first 👍

[come-nc]

Approving for @kesselb

[backportbot]

The backport to stable28 failed. Please do this backport manually.

# Switch to the target branch and update it
git checkout stable28
git pull origin stable28

# Create the new backport branch
git checkout -b backport/46255/stable28

# Cherry pick the change from the commit sha1 of the change against the default branch
# This might cause conflicts, resolve them
git cherry-pick 4ce4d7b9 c224b8ce

# Push the cherry pick commit to the remote repository and open a pull request
git push origin backport/46255/stable28

Error: No changes found in backport branch

---

Learn more about backports at https://docs.nextcloud.com/server/stable/go.php?to=developer-backports.