No 'Authorization: Basic' header found

mcnesium commented 6 years ago

For about a week now my Nextcloud Calendars will not show up on my iOS device anymore, after this worked well for ages. I deleted and re-added the CalDAV account. When I added the credentials, the iOS complained, it cannot connect using SSL, though the certificate is valid and rated A+.

When I toggled the Calendars switch, the following was written to nextcloud.log:

{"reqId":"YroUHvIWhjVsrwKTDBMU","level":0,"time":"2018-01-23T19:12:52+00:00","remoteAddr":"2a02:2450:20d2:f:1c3a:cf22:2d48:2a23","user":"--","app":"webdav","method":"OPTIONS","url":"\/remote.php\/dav\/principals\/users\/mcnesium\/","message":"Exception: {\"Exception\":\"Sabre\\\\DAV\\\\Exception\\\\NotAuthenticated\",\"Message\":\"No public access to this resource., No 'Authorization: Basic' header found. Either the client didn't send one, or the server is misconfigured, No 'Authorization: Bearer' header found. Either the client didn't send one, or the server is mis-configured, No 'Authorization: Basic' header found. Either the client didn't send one, or the server is misconfigured\",\"Code\":0,\"Trace\":\"#0 [internal function]: Sabre\\\\DAV\\\\Auth\\\\Plugin->beforeMethod(Object(Sabre\\\\HTTP\\\\Request), Object(Sabre\\\\HTTP\\\\Response))\\n#1 \\\/var\\\/www\\\/cloud.elektrat.de\\\/3rdparty\\\/sabre\\\/event\\\/lib\\\/EventEmitterTrait.php(105): call_user_func_array(Array, Array)\\n#2 \\\/var\\\/www\\\/cloud.elektrat.de\\\/3rdparty\\\/sabre\\\/dav\\\/lib\\\/DAV\\\/Server.php(466): Sabre\\\\Event\\\\EventEmitter->emit('beforeMethod', Array)\\n#3 \\\/var\\\/www\\\/cloud.elektrat.de\\\/3rdparty\\\/sabre\\\/dav\\\/lib\\\/DAV\\\/Server.php(254): Sabre\\\\DAV\\\\Server->invokeMethod(Object(Sabre\\\\HTTP\\\\Request), Object(Sabre\\\\HTTP\\\\Response))\\n#4 \\\/var\\\/www\\\/cloud.elektrat.de\\\/apps\\\/dav\\\/lib\\\/Server.php(258): Sabre\\\\DAV\\\\Server->exec()\\n#5 \\\/var\\\/www\\\/cloud.elektrat.de\\\/apps\\\/dav\\\/appinfo\\\/v2\\\/remote.php(33): OCA\\\\DAV\\\\Server->exec()\\n#6 \\\/var\\\/www\\\/cloud.elektrat.de\\\/remote.php(162): require_once('\\\/var\\\/www\\\/cloud....')\\n#7 {main}\",\"File\":\"\\\/var\\\/www\\\/cloud.elektrat.de\\\/3rdparty\\\/sabre\\\/dav\\\/lib\\\/DAV\\\/Auth\\\/Plugin.php\",\"Line\":168}","userAgent":"iOS\/9.3.5 (13G36) dataaccessd\/1.0","version":"12.0.4.3"}
{"reqId":"BX7UOtyKN3SRrIqvHWO3","level":0,"time":"2018-01-23T19:12:53+00:00","remoteAddr":"2a02:2450:20d2:f:1c3a:cf22:2d48:2a23","user":"--","app":"webdav","method":"PROPFIND","url":"\/remote.php\/dav\/addressbooks\/users\/mcnesium\/","message":"Exception: {\"Exception\":\"Sabre\\\\DAV\\\\Exception\\\\NotAuthenticated\",\"Message\":\"No public access to this resource., No 'Authorization: Basic' header found. Either the client didn't send one, or the server is misconfigured, No 'Authorization: Bearer' header found. Either the client didn't send one, or the server is mis-configured, No 'Authorization: Basic' header found. Either the client didn't send one, or the server is misconfigured\",\"Code\":0,\"Trace\":\"#0 [internal function]: Sabre\\\\DAV\\\\Auth\\\\Plugin->beforeMethod(Object(Sabre\\\\HTTP\\\\Request), Object(Sabre\\\\HTTP\\\\Response))\\n#1 \\\/var\\\/www\\\/cloud.elektrat.de\\\/3rdparty\\\/sabre\\\/event\\\/lib\\\/EventEmitterTrait.php(105): call_user_func_array(Array, Array)\\n#2 \\\/var\\\/www\\\/cloud.elektrat.de\\\/3rdparty\\\/sabre\\\/dav\\\/lib\\\/DAV\\\/Server.php(466): Sabre\\\\Event\\\\EventEmitter->emit('beforeMethod', Array)\\n#3 \\\/var\\\/www\\\/cloud.elektrat.de\\\/3rdparty\\\/sabre\\\/dav\\\/lib\\\/DAV\\\/Server.php(254): Sabre\\\\DAV\\\\Server->invokeMethod(Object(Sabre\\\\HTTP\\\\Request), Object(Sabre\\\\HTTP\\\\Response))\\n#4 \\\/var\\\/www\\\/cloud.elektrat.de\\\/apps\\\/dav\\\/lib\\\/Server.php(258): Sabre\\\\DAV\\\\Server->exec()\\n#5 \\\/var\\\/www\\\/cloud.elektrat.de\\\/apps\\\/dav\\\/appinfo\\\/v2\\\/remote.php(33): OCA\\\\DAV\\\\Server->exec()\\n#6 \\\/var\\\/www\\\/cloud.elektrat.de\\\/remote.php(162): require_once('\\\/var\\\/www\\\/cloud....')\\n#7 {main}\",\"File\":\"\\\/var\\\/www\\\/cloud.elektrat.de\\\/3rdparty\\\/sabre\\\/dav\\\/lib\\\/DAV\\\/Auth\\\/Plugin.php\",\"Line\":168}","userAgent":"iOS\/9.3.5 (13G36) dataaccessd\/1.0","version":"12.0.4.3"}

So I am wondering, what might have happened to my setup, as I cannot tell what has changed. iOS 9.3.5 is way end of life and Nextcloud calendar has not been updated for more than a month. How come this stopped working? Any ideas?

mcnesium commented 6 years ago

Interesting side note: the corresponding CardDAV connection works fine from that device to the same Nextcloud instance.

mcnesium commented 6 years ago

same situation after upgrading NC to v12.0.5.3

georg90 commented 6 years ago

EDIT: My issue is fixed somehow, I didn't change anything, just went to bed for 10 hours and it helped! Now syncing with NC13 & iOS 11! Carddav & Caldav

I have the same issue with NC13 and iOS11. Any idea?

I run NC with apache, the .htaccess works fine. Desktop app works with app token & mobile app registers but is not showing data.

Funny fact: When I updated to NC13 (from NC12) it all worked but when I changed my password to NC, the apps won't sync with the newly created app tokens.

mcnesium commented 6 years ago

I ~~solved this~~ got rid of this problem by not entering just the domain of the nextcloud instance but the entire iOS/OSX url proposed in the "Settings & import" section on the lower left of the calendar app. This should actually not be necessary because of CalDAV auto-discovery and it did work fine for quite while, but oh well…

georg90 commented 6 years ago

Same for me, I remember adding the complete path (iOS caldav path) and it worked, but when I closed settings and went back again, it will cut the URL to the main URL and it seemes like its using auto discovery. Anyway it’s working again :-)

avanc commented 6 years ago

I get the same error. However, I use the export url to integrate the calendar as internet calendar in outlook:

mynextcloud/remote.php/dav/calendars/username/default?export

I'm not sure if it happened while updating from 12.x to 13 or while moving from outlook 2010 to 2016. Any idea how to change the behaviour?

havrla commented 6 years ago

Heloo,

same problem after install package php-pear-Auth-SASL on system Centos7 with php71w and NC12.0.6

Recovery from snapshot :-), remove package no effect.

Havrla

mailanetworks commented 6 years ago

Hello,

NC 13.0.0.14 here, PHP 7.2. Works on Windows10 client but not on MacOS and iOS.

Thanks,

lenusch commented 6 years ago

Same here with NC 13.0.1: Sabre\DAV\Exception\NotAuthenticated: No 'Authorization: Basic' header found. Either the client didn't send one, or the server is misconfigured

.... Just happened can't tell why. This was a new installation.

hudecof commented 6 years ago

+1

next cloud 13.0.1
Mac OS 10.13.3

shoelzle commented 6 years ago

+1

MacOS 10.13.4
nextcloud 13.0.1
php 7.1.16

While investigating the issue I tried to use MacOS's addressbook app and calendar app. I noticed a few things:

The calendar app synchronizes successfully although the webserver's access log says

IP - - [24/Apr/2018:20:38:24 +0200] "PROPFIND /remote.php/dav/calendars/username/ HTTP/1.1" 401 557 "-" "Mac+OS+X/10.13.4 (17E199) CalendarAgent/399.2.2" "-"

and the nextcloud log says

{"reqId":"asdf","level":0,"time":"2018-04-24T18:38:24+00:00","remoteAddr":"IP","user":"--","app":"webdav","method":"PROPFIND","url":"\/remote.php\/dav\/calendars\/username\/","messag
e":"Exception: {\"Exception\":\"Sabre\\\\DAV\\\\Exception\\\\NotAuthenticated\",\"Message\":\"No public access to this resource., No 'Authorization: Basic' header found. Either the client didn't send one,
or the server is misconfigured, No 'Authorization: Bearer' header found. Either the client didn't send one, or the server is mis-configured, No 'Authorization: Basic' header found. Either the client didn
't send one, or the server is misconfigured\",\"Code\":0,\"Trace\":\"#0 [internal function]: Sabre\\\\DAV\\\\Auth\\\\Plugin->beforeMethod(Object(Sabre\\\\HTTP\\\\Request), Object(Sabre\\\\HTTP\\\\Response
))\\n#1 \\\/var\\\/www\\\/html\\\/3rdparty\\\/sabre\\\/event\\\/lib\\\/EventEmitterTrait.php(105): call_user_func_array(Array, Array)\\n#2 \\\/var\\\/www\\\/html\\\/3rdparty\\\/sabre\\\/dav\\\/lib\\\/DAV\
\\/Server.php(466): Sabre\\\\Event\\\\EventEmitter->emit('beforeMethod', Array)\\n#3 \\\/var\\\/www\\\/html\\\/3rdparty\\\/sabre\\\/dav\\\/lib\\\/DAV\\\/Server.php(254): Sabre\\\\DAV\\\\Server->invokeMeth
od(Object(Sabre\\\\HTTP\\\\Request), Object(Sabre\\\\HTTP\\\\Response))\\n#4 \\\/var\\\/www\\\/html\\\/apps\\\/dav\\\/lib\\\/Server.php(283): Sabre\\\\DAV\\\\Server->exec()\\n#5 \\\/var\\\/www\\\/html\\\/
apps\\\/dav\\\/appinfo\\\/v2\\\/remote.php(35): OCA\\\\DAV\\\\Server->exec()\\n#6 \\\/var\\\/www\\\/html\\\/remote.php(164): require_once('\\\/var\\\/www\\\/html\\\/a...')\\n#7 {main}\",\"File\":\"\\\/var
\\\/www\\\/html\\\/3rdparty\\\/sabre\\\/dav\\\/lib\\\/DAV\\\/Auth\\\/Plugin.php\",\"Line\":168}","userAgent":"Mac+OS+X\/10.13.4 (17E199) CalendarAgent\/399.2.2","version":"13.0.1.1"}

The addressbook does not sync at all with the almost the same messages in the logs. The only difference being the different URL path.
In both cases the Authentication header is not set. I know this because the last part of the access log format is the header (the last "-").
If I set the Authentication header in the apache config manually, the MacOS apps ask me for a password in a pop-up window. If I enter the password the sync does not work not all with both apps and the pop-up window reappears.

ax-meyer commented 6 years ago

I have the same problem, with the PhotoSync App and Webdav.

Had the problem for a couple of months now, but only started investigating now. First apperance of the problem was about the time of the first posting here.

PanCakeConnaisseur commented 6 years ago

Same problem with with Nextcloud 13.0.4 Kontact 5.8.2, Evolution 3.18.5.2 und Thunderbird 52.8.0+SoGoConnector 31.0.5.

An example log when using Kontact:

nextcloud[18252]: {webdav} Exception: {"Exception":"Sabre\\DAV\\Exception\\NotAuthenticated","Message":"No public access to this resource., No 'Authorization: Basic' header fou
nd. Either the client didn't send one, or the server is misconfigured, No 'Authorization: Bearer' header found. Either the client didn't send one, or the server is mis-configured, No 'Authorization
: Basic' header found. Either the client didn't send one, or the server is misconfigured","Code":0,"Trace":"#0 [internal function]: Sabre\\DAV\\Auth\\Plugin->beforeMethod(Object(Sabre\\HTTP\\Reques
t), Object(Sabre\\HTTP\\Response))\n#1 \/var\/www\/nextcloud\/3rdparty\/sabre\/event\/lib\/EventEmitterTrait.php(105): call_user_func_array(Array, Array)\n#2 \/var\/www\/nextcloud\/3rdparty\/sabre\
/dav\/lib\/DAV\/Server.php(466): Sabre\\Event\\EventEmitter->emit('beforeMethod', Array)\n#3 \/var\/www\/nextcloud\/3rdparty\/sabre\/dav\/lib\/DAV\/Server.php(254): Sabre\\DAV\\Server->invokeMethod
(Object(Sabre\\HTTP\\Request), Object(Sabre\\HTTP\\Response))\n#4 \/var\/www\/nextcloud\/apps\/dav\/lib\/Server.php(287): Sabre\\DAV\\Server->exec()\n#5 \/var\/www\/nextcloud\/apps\/dav\/appinfo\/v
2\/remote.php(35): OCA\\DAV\\Server->exec()\n#6 \/var\/www\/nextcloud\/remote.php(164): require_once('\/var\/www\/nextcl...')\n#7 {main}","File":"\/var\/www\/nextcloud\/3rdparty\/sabre\/dav\/lib\/D
AV\/Auth\/Plugin.php","Line":168}

leschard commented 6 years ago

Did you check the version of calendar application?

I figured out that my Nextcloud instance did no longer check the calendar pluggin version and did no longer display any notification for available calendar upgrade. I had to upgrade it manually to the latest version to solve the problem.

PanCakeConnaisseur commented 6 years ago

Did you check the version of calendar application?

Yes, I am using the current Calendar version 1.6.1.

Grunthos commented 6 years ago

I don't know if this is relevant but I had the same problem, and above the exception I noticed "Brute force attack detected" because I had several devices and had just changed the password.

Also, my Brute-Force app was out of date and could not be configured. Updating the app and adding the IP to the exclusions fixed all the problems.

I'm guessing the person for whom the problem just cleared up was subsequently removed from the brute-force list.

gjedeer commented 6 years ago

Same here with Nextcloud Android app

{"reqId":"eSU01CFbver4tFSE7iWl","level":1,"time":"2018-08-16T06:15:55+00:00","remoteAddr":"xxmyipxx","user":"--","app":"admin_audit","method":"PUT","url":"\/remote.php\/webdav\/InstantUpload\/Conversations%20Images\/899fc1af-e594-4edf-8d34-ed0079bef9fe.jpg","message":"Login attempt: \"xxmyusernamexx\"","userAgent":"Mozilla\/5.0 (Android) ownCloud-android\/3.2.1","version":"13.0.4.0"}
{"reqId":"eSU01CFbver4tFSE7iWl","level":2,"time":"2018-08-16T06:15:55+00:00","remoteAddr":"xxmyipxx","user":"--","app":"core","method":"PUT","url":"\/remote.php\/webdav\/InstantUpload\/Conversations%20Images\/899fc1af-e594-4edf-8d34-ed0079bef9fe.jpg","message":"Login failed: 'xxmyusernamexx' (Remote IP: 'xxmyipxx')","userAgent":"Mozilla\/5.0 (Android) ownCloud-android\/3.2.1","version":"13.0.4.0"}
{"reqId":"eSU01CFbver4tFSE7iWl","level":1,"time":"2018-08-16T06:15:55+00:00","remoteAddr":"xxmyipxx","user":"--","app":"core","method":"PUT","url":"\/remote.php\/webdav\/InstantUpload\/Conversations%20Images\/899fc1af-e594-4edf-8d34-ed0079bef9fe.jpg","message":"Bruteforce attempt from \"xxmyipxx\" detected for action \"login\".","userAgent":"Mozilla\/5.0 (Android) ownCloud-android\/3.2.1","version":"13.0.4.0"}
{"reqId":"eSU01CFbver4tFSE7iWl","level":0,"time":"2018-08-16T06:15:55+00:00","remoteAddr":"xxmyipxx","user":"--","app":"webdav","method":"PUT","url":"\/remote.php\/webdav\/InstantUpload\/Conversations%20Images\/899fc1af-e594-4edf-8d34-ed0079bef9fe.jpg","message":"Exception: {\"Exception\":\"Sabre\\\\DAV\\\\Exception\\\\NotAuthenticated\",\"Message\":\"Username or password was incorrect, No 'Authorization: Bearer' header found. Either the client didn't send one, or the server is mis-configured\",\"Code\":0,\"Trace\":\"#0 [internal function]: Sabre\\\\DAV\\\\Auth\\\\Plugin->beforeMethod(Object(Sabre\\\\HTTP\\\\Request), Object(Sabre\\\\HTTP\\\\Response))\\n#1 \\\/var\\\/www\\\/3rdparty\\\/sabre\\\/event\\\/lib\\\/EventEmitterTrait.php(105): call_user_func_array(Array, Array)\\n#2 \\\/var\\\/www\\\/3rdparty\\\/sabre\\\/dav\\\/lib\\\/DAV\\\/Server.php(466): Sabre\\\\Event\\\\EventEmitter->emit('beforeMethod', Array)\\n#3 \\\/var\\\/www\\\/3rdparty\\\/sabre\\\/dav\\\/lib\\\/DAV\\\/Server.php(254): Sabre\\\\DAV\\\\Server->invokeMethod(Object(Sabre\\\\HTTP\\\\Request), Object(Sabre\\\\HTTP\\\\Response))\\n#4 \\\/var\\\/www\\\/apps\\\/dav\\\/appinfo\\\/v1\\\/webdav.php(80): Sabre\\\\DAV\\\\Server->exec()\\n#5 \\\/var\\\/www\\\/remote.php(164): require_once('\\\/var\\\/www\\\/apps\\\/d...')\\n#6 {main}\",\"File\":\"\\\/var\\\/www\\\/3rdparty\\\/sabre\\\/dav\\\/lib\\\/DAV\\\/Auth\\\/Plugin.php\",\"Line\":168}","userAgent":"Mozilla\/5.0 (Android) ownCloud-android\/3.2.1","version":"13.0.4.0"}

EDIT: Worked around this problem by using app passwords.

coldtobi commented 6 years ago

I've had this isse too; For me is seems had to be caused by the brute-force plugin: A user has changed their password but still had a client trying to connect to is. Symptom for me was that the log contained :

The app to connect to the nextcloud was the Android nextcloud app (as well as keepass4android)

Debug   webdav  Sabre\DAV\Exception\NotAuthenticated: No 'Authorization: Basic' header found. Either the client didn't send one, or the server is misconfigured, No 'Authorization: Bearer' header found. Either the client didn't send one, or the server is mis-configured    2018-08-18T16:45:50+0200
Debug   webdav  Sabre\DAV\Exception\NotAuthenticated: Username or password was incorrect, No 'Authorization: Bearer' header found. Either the client didn't send one, or the server is mis-configured   2018-08-18T16:45:46+0200
Info    core    Bruteforce attempt from "xxx.xxx.xxx.xxx" detected for action "login". 2018-08-18T16:45:46+0200
Warning core    Login failed: '<user>' (Remote IP: 'xxx.xxx.xxx.xxx')   2018-08-18T16:45:46+0200

Deactivating the brute-force plugin did not help, I did remove it later and it worked again, but this could be co-incidal with some timeout of the ban.Interestingly, I could still login using the webinterface (but maybe this because I'm admin?). Another data point: Not only the banned user was affected, also me (we were on the banned ip)

Twilek-de commented 6 years ago

I have the problem with photosync. I am using NC 13.0.0.5 and PHP 7.2. It has started when I switched to an FPM Installation of PHP and the event version of Apache. Switching back to the prefork apache and libmod php "solved" the problem.

Twilek-de commented 6 years ago

I switched to FPM and kept prefork. Keeps working. Switching to worker or event produces the error.

coldtobi commented 6 years ago

Im using fpm as well (but on nginx) but this has always been that way. There were zero changes on the config when the breakage happened.

Twilek-de commented 6 years ago

I cannot speak for Nginx (which is inherently event driven) but for me changing the MPM of Apache turns the error on and off. Maybe someone with an apache installation and the same problem might check this out. Althought I have not the faintest clue why the MPM should affect this behaviour.

Twilek-de commented 6 years ago

Problem with Apache mpm event and prefork persists in NC 14.

WMP commented 6 years ago

I have this same on Apache 2.4 with PHP-FPM or libapache2-mod-php7.0 , when i try to add webdav to my Windows 10 with kerberos support. Tomorrow i try to configure this on nginx.

marci4 commented 6 years ago

Switching to FPM for nginx instead of FastCGI fixed it for me!

gjedeer commented 6 years ago

Had this problem again after switching from mod_php to FPM, followed this advice:

https://stackoverflow.com/questions/17018586/apache-2-4-php-fpm-and-authorization-headers

Basically, added this just above ProxyPassMatch:

SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1

hieronymousch commented 5 years ago

Have the same problem after upgrading to NC14 on a virtualmin environment. Changing from fpm to cgi etc doesn't change anything. I added the SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1 in the config file and users have access now but still errors in the logfile. Would love to see a more structural solution

RussianNeuroMancer commented 5 years ago

I have same issue on Ubuntu 18.04 with Apache 2.4.29 and PHP-FPM 7.2.15. Passing HTTP_AUTHORIZATION is already there, in default configuration: https://packages.ubuntu.com/bionic-updates/amd64/php7.2-fpm/filelist

# Redirect to local php-fpm if mod_php is not available
<IfModule !mod_php7.c>
<IfModule proxy_fcgi_module>
    # Enable http authorization headers
    <IfModule setenvif_module>
    SetEnvIfNoCase ^Authorization$ "(.+)" HTTP_AUTHORIZATION=$1
    </IfModule>

    <FilesMatch ".+\.ph(ar|p|tml)$">
        SetHandler "proxy:unix:/run/php/php7.2-fpm.sock|fcgi://localhost"
    </FilesMatch>
    <FilesMatch ".+\.phps$">
        # Deny access to raw php sources by default
        # To re-enable it's recommended to enable access to the files
        # only in specific virtual host or directory
        Require all denied
    </FilesMatch>
    # Deny access to files without filename (e.g. '.php')
    <FilesMatch "^\.ph(ar|p|ps|tml)$">
        Require all denied
    </FilesMatch>
</IfModule>
</IfModule>

What else could cause this error? It's appear on attempt to authorize Nextcloud Android client with application token and login/password.

Sabre\DAV\Exception\NotAuthenticated: No 'Authorization: Basic' header found. Either the client didn't send one, or the server is misconfigured, No 'Authorization: Bearer' header found. Either the client didn't send one, or the server is mis-configured

kesselb commented 5 years ago

Is setenvif_module enabled?

RussianNeuroMancer commented 5 years ago

I also found that due to this error sending files between Nextcloud instances is also broken.

@kesselb yes:

~$ apache2ctl -t -D DUMP_MODULES | grep env
 env_module (shared)
 setenvif_module (shared)

scradster commented 5 years ago

After hours of searching I was able to fix this by simply using an app password.

RussianNeuroMancer commented 5 years ago

@jschweingruber I getting this error even when one Nextcloud instance trying to change file on another Nextcloud instance. Edited file in folder that shared with own Nextcloud federated sharing.

Is anyone know how to debug it further?

t2d commented 5 years ago

I had the same error. It was caused by updating external_users from 0.5.1 to 0.6.1. The problem was that the desktop client couldn't sync shares of users that hadn't logged in after the update. Somehow nc just didn't know anymore about these users after the update. As soon as the user, whose share I was using had logged in, everything was back to normal.

myrdd commented 5 years ago

I can confirm the Warning—Login failed: 'my_username' (Remote IP: 'xxx.xxx.xxx.xxx')—occurres when the Remote IP is banned. I can also confirm that deactivating brute force protection (auth.bruteforce.protection.enabled) doesn't fix the issue (as @coldtobi already said).

I was finally able to fix the issue by removing my own IP from the oc_bruteforce_attempts database table. See https://help.nextcloud.com/t/how-can-i-unblock-an-ip-blocked-through-brute-force-detection/5731

To check if your IP is on the list, run this SQL query: SELECT * FROM oc_bruteforce_attempts;

I could still login using the webinterface (but maybe this because I'm admin?).

I could still log in using the webinterface as a non-admin.

FWIW, I've probably been running into this issue because I'm running NC behind sniproxy, so NC always sees the proxy's IP as the remote IP.

Lumrenion commented 3 years ago

My environment: Official Nextcloud Docker container behind a Traefik reverse proxy. Authentication via SAML - to authenticate CalDAV, I created a new device in security settings (suggested here: https://github.com/nextcloud/user_saml/issues/226#issuecomment-468832506). Browser-Login as well as the desktop client did work properly, but when trying to add a CalDAV client, I got the Exception "No public access to this resource., No 'Authorization: Bearer' header found. Either the client didn't send one, or the server is mis-configured, No 'Authorization: Basic' header found. Either the client didn't send one, or the server is misconfigured".

I can confirm, after clearing the table "oc_bruteforce_attempts", as @myrdd suggested, I connection via CalDAV works as intended. In this case, the error message is definately missleading.

Stringboom commented 3 years ago

Had this problem again after switching from mod_php to FPM, followed this advice:

https://stackoverflow.com/questions/17018586/apache-2-4-php-fpm-and-authorization-headers

Basically, added this just above ProxyPassMatch:
SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1

Thank you So much

szaimen commented 3 years ago

So it seems like this is a configuration issue, right?

wanno-drijfhout commented 3 years ago

I've been trying to debug this error. Here some extra information on what seems to work and not work; I'm still trying to triangulate the problem. Does anyone have interesting thoughts on what's going on here?

Does anyone know what could cause a CalDAV client to not even send an Authorization header?

Configuration

My usual configuration is: Docker Swarm, a Traefik reverse proxy with Let's Encrypt certificates and a subdomain for my Nextcloud instance. For debugging, I switched to unencrypted HTTP and ran Wireshark on my Windows desktop.

Nextcloud v22.0.0.

I use 2FA and generated apptokens to log on for all my applications below.

My server is configured with:

  'trusted_proxies' =>
  array (
    0 => '10.69.0.0/16',
  ),

and environment variable "APACHE_DISABLE_REWRITE_IP=1"

I have also configured the .well-known/(card|cal)dav forwards (properly, according to the Nextcloud server check).

Thunderbird

It doesn't send an Authorization header. I noticed I'm not prompted for a password by Thunderbird/Lightning. afbeelding

TbSync

I have also used TbSync. Interestingly, the CardDAV is synchronized properly but the CalDAV calendars aren't. All my CalDAV calendars are listed and they are "fetched", but it seems they are fetched without content. afbeelding

eM client

eM Client does prompt for a password but somehow still just doesn't submit it to the server via Authorization header either. afbeelding

Windows 10 Calendar

Surprisingly, this application does work with Nextcloud's CalDAV sync (via the iCloud hack) on HTTPS. (Didn't diagnose traffic for this one.)

Android

Didn't diagnose with Wireshark; this evidence is anecdotal.

KeePassXC

Does not work via direct Nextcloud connection. This is file storage and may be completely unrelated. Still: authorization problem Currently using the Nextcloud app to sync the KDBX-file between phone and server, rather than a direct connection from KeePass -- this works.

Nextcloud app

The official Nextcloud file storage app works. Of course, it just does something different (file storage via WebDAV), but it goes to show there's no fundamental problem with app token credentials.

DAVx5

Seems to work, sort of. I recall that I had to try it a lot and at some point I didn't get 401 errors anymore and "it worked".

Brute force attempts

I've seen some people have issues with the brute force attempts. I don't know if that's a problem here. I notice that there's a weird entry in my table. (Perhaps I configured trusted_proxies too late?). But it's a different IP (.101 instead of .100) so it should not be relevant for the above test results.

SELECT * FROM oc_bruteforce_attempts;
 id | action |  occurred  |     ip      |     subnet     |  metadata
----+--------+------------+-------------+----------------+-------------
  4 | login  | 1627173934 | 10.69.1.101 | 10.69.1.101/32 | {"user":""}

I deleted that entry and redid some testing afterwards, but to no avail. Table stays empty too.

ghost commented 3 years ago

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.

wanno-drijfhout commented 3 years ago

I fixed my problem by removing some middleware from Traefik. It was self-inflicted. Sorry!

Traefik previously intercepted error responses by custom static error pages. I shouldn't have done this; I reckon the 4xx responses by Nextcloud contain important headers/bodies that clients may need to interpret to logon. Not just browsers with users stumbling upon 401 and 403 errors, I suppose :-).

Example of the wrong Docker stack labels:

- "traefik.http.routers.static-app.middlewares=static-app-errorpages"
- "traefik.http.middlewares.static-app-errorpages.errors.status=400,401,403,404,409,500"

szaimen commented 3 years ago

Thanks for the feedback. Closing because of config issue.

nextcloud / server