Problem with authentication headers #13398

LukasReschke · 2015-01-15T17:30:04Z

While demoing S2S with @jnfrmarks, @craigpg and @schiesbn today we found that S2S was completely broken in this setup using PHP-FPM.

As far I can see the remote server is not properly reading the user from the Basic Auth Header and thus is failing completely.

I'm on it.

➜  ~  curl --trace-ascii - -X PROPFIND -D - http://Ifo0BaFTc5UYiyu@172.18.5.74/owncloud/public.php/webdav/
== Info: Hostname was NOT found in DNS cache
== Info:   Trying 172.18.5.74...
== Info: Connected to 172.18.5.74 (172.18.5.74) port 80 (#0)
== Info: Server auth using Basic with user 'Ifo0BaFTc5UYiyu'
=> Send header, 154 bytes (0x9a)
0000: PROPFIND /owncloud/public.php/webdav/ HTTP/1.1
0030: Authorization: Basic SWZvMEJhRlRjNVVZaXl1Og==
005f: User-Agent: curl/7.37.1
0078: Host: 172.18.5.74
008b: Accept: */*
0098: 
<= Recv header, 27 bytes (0x1b)
0000: HTTP/1.1 401 Unauthorized
HTTP/1.1 401 Unauthorized
<= Recv header, 37 bytes (0x25)
0000: Date: Thu, 15 Jan 2015 17:24:50 GMT
Date: Thu, 15 Jan 2015 17:24:50 GMT
== Info: Server Apache/2.4.7 (Ubuntu) is not blacklisted
<= Recv header, 31 bytes (0x1f)
0000: Server: Apache/2.4.7 (Ubuntu)
Server: Apache/2.4.7 (Ubuntu)
<= Recv header, 36 bytes (0x24)
0000: X-Powered-By: PHP/5.5.9-1ubuntu4.4
X-Powered-By: PHP/5.5.9-1ubuntu4.4
<= Recv header, 79 bytes (0x4f)
0000: Set-Cookie: oc5nfs3kn48o=l9bvpoanv5f6qs91k8biu49mi7; path=/owncl
0040: oud; HttpOnly
Set-Cookie: oc5nfs3kn48o=l9bvpoanv5f6qs91k8biu49mi7; path=/owncloud; HttpOnly
<= Recv header, 40 bytes (0x28)
0000: Expires: Thu, 19 Nov 1981 08:52:00 GMT
Expires: Thu, 19 Nov 1981 08:52:00 GMT
<= Recv header, 79 bytes (0x4f)
0000: Cache-Control: no-store, no-cache, must-revalidate, post-check=0
0040: , pre-check=0
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
<= Recv header, 18 bytes (0x12)
0000: Pragma: no-cache
Pragma: no-cache
<= Recv header, 33 bytes (0x21)
0000: X-XSS-Protection: 1; mode=block
X-XSS-Protection: 1; mode=block
<= Recv header, 33 bytes (0x21)
0000: X-Content-Type-Options: nosniff
X-Content-Type-Options: nosniff
<= Recv header, 29 bytes (0x1d)
0000: X-Frame-Options: Sameorigin
X-Frame-Options: Sameorigin
<= Recv header, 187 bytes (0xbb)
0000: Content-Security-Policy: default-src 'self'; script-src 'self' '
0040: unsafe-eval'; style-src 'self' 'unsafe-inline'; frame-src *; img
0080: -src *; font-src 'self' data:; media-src *; connect-src *
Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; frame-src *; img-src *; font-src 'self' data:; media-src *; connect-src *
<= Recv header, 20 bytes (0x14)
0000: X-Robots-Tag: none
X-Robots-Tag: none
== Info: Authentication problem. Ignoring this.
<= Recv header, 42 bytes (0x2a)
0000: WWW-Authenticate: Basic realm="ownCloud"
WWW-Authenticate: Basic realm="ownCloud"
<= Recv header, 21 bytes (0x15)
0000: Content-Length: 242
Content-Length: 242
<= Recv header, 46 bytes (0x2e)
0000: Content-Type: application/xml; charset=utf-8
Content-Type: application/xml; charset=utf-8

<= Recv header, 2 bytes (0x2)
0000: 
<= Recv data, 242 bytes (0xf2)
0000: <?xml version="1.0" encoding="utf-8"?>.<d:error xmlns:d="DAV:" x
0040: mlns:s="http://sabredav.org/ns">.  <s:exception>Sabre\DAV\Except
0080: ion\NotAuthenticated</s:exception>.  <s:message>No basic authent
00c0: ication headers were found</s:message>.</d:error>.
<?xml version="1.0" encoding="utf-8"?>
<d:error xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns">
  <s:exception>Sabre\DAV\Exception\NotAuthenticated</s:exception>
  <s:message>No basic authentication headers were found</s:message>
</d:error>
== Info: Connection #0 to host 172.18.5.74 left intact

I'm on it.

The text was updated successfully, but these errors were encountered:

LukasReschke · 2015-01-15T17:35:23Z

Potential duplicates: #12146, #13228, #13044, #12018, #10872, #10503, #10132, #9880, #9416 and possibly many many more…

LukasReschke · 2015-01-15T18:22:06Z

This specific error in this case is caused by https://github.com/owncloud/3rdparty/blob/master/sabre/dav/lib/Sabre/DAV/Auth/Backend/AbstractBasic.php#L71-L74

if (!$userpass) {
     $auth->requireLogin();
     throw new DAV\Exception\NotAuthenticated('No basic authentication headers were found');
}

Because the password is an empty value… digging further…

LukasReschke · 2015-01-15T18:37:21Z

$this->httpRequest has the following values on that server in \Sabre\HTTP\BasicAuth::getUserPass:

OC_Connector_Sabre_Request Object
(
    [_SERVER:protected] => Array
        (
            [HTTP_USER_AGENT] => curl/7.37.1
            [HTTP_HOST] => 172.18.5.74
            [HTTP_ACCEPT] => */*
            [PATH] => /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
            [SERVER_SIGNATURE] => <address>Apache/2.4.7 (Ubuntu) Server at 172.18.5.74 Port 80</address>

            [SERVER_SOFTWARE] => Apache/2.4.7 (Ubuntu)
            [SERVER_NAME] => 172.18.5.74
            [SERVER_ADDR] => 172.18.5.74
            [SERVER_PORT] => 80
            [REMOTE_ADDR] => 172.16.12.73
            [DOCUMENT_ROOT] => /var/www/html
            [REQUEST_SCHEME] => http
            [CONTEXT_PREFIX] => 
            [CONTEXT_DOCUMENT_ROOT] => /var/www/html
            [SERVER_ADMIN] => webmaster@localhost
            [SCRIPT_FILENAME] => /var/www/html/owncloud/public.php
            [REMOTE_PORT] => 64946
            [GATEWAY_INTERFACE] => CGI/1.1
            [SERVER_PROTOCOL] => HTTP/1.1
            [REQUEST_METHOD] => PROPFIND
            [QUERY_STRING] => 
            [REQUEST_URI] => /owncloud/public.php/webdav/
            [SCRIPT_NAME] => /owncloud/public.php
            [PATH_INFO] => /webdav/
            [PATH_TRANSLATED] => /var/www/html/webdav/
            [PHP_SELF] => /owncloud/public.php/webdav/
            [PHP_AUTH_USER] => Ifo0BaFTc5UYiyu
            [PHP_AUTH_PW] => 
            [REQUEST_TIME_FLOAT] => 1421346729.778
            [REQUEST_TIME] => 1421346729
        )

    [_POST:protected] => Array
        (
        )

    [body:protected] => 
)

On my local machine:

OC_Connector_Sabre_Request Object
(
    [_SERVER:protected] => Array
        (
            [UNIQUE_ID] => VLgH8MCoABEAAPK43Y4AAAAD
            [htaccessWorking] => true
            [HTTP_AUTHORIZATION] => Basic SWZvMEJhRlRjNVVZaXl1Og==
            [HTTP_USER_AGENT] => curl/7.37.1
            [HTTP_HOST] => localhost
            [HTTP_ACCEPT] => */*
            [PATH] => /usr/bin:/bin:/usr/sbin:/sbin
            [SERVER_SIGNATURE] => 
            [SERVER_SOFTWARE] => ownCloud
            [SERVER_NAME] => localhost
            [SERVER_ADDR] => ::1
            [SERVER_PORT] => 80
            [REMOTE_ADDR] => ::1
            [DOCUMENT_ROOT] => /Users/lreschke/Programming/core
            [REQUEST_SCHEME] => http
            [CONTEXT_PREFIX] => 
            [CONTEXT_DOCUMENT_ROOT] => /Users/lreschke/Programming/core
            [SERVER_ADMIN] => you@example.com
            [SCRIPT_FILENAME] => /Users/lreschke/Programming/core/public.php
            [REMOTE_PORT] => 64958
            [GATEWAY_INTERFACE] => CGI/1.1
            [SERVER_PROTOCOL] => HTTP/1.1
            [REQUEST_METHOD] => PROPFIND
            [QUERY_STRING] => 
            [REQUEST_URI] => /public.php/webdav/
            [SCRIPT_NAME] => /public.php
            [PATH_INFO] => /webdav/
            [PATH_TRANSLATED] => /Users/lreschke/Programming/core/webdav/
            [PHP_SELF] => /public.php/webdav/
            [PHP_AUTH_USER] => Ifo0BaFTc5UYiyu
            [PHP_AUTH_PW] => 
            [REQUEST_TIME_FLOAT] => 1421346800.839
            [REQUEST_TIME] => 1421346800
        )

    [_POST:protected] => Array
        (
        )

    [body:protected] => 
)

The difference here is the HTTP_AUTHORIZATION variable which is populated in my case and in the case of the remote server is not.

I'm wondering why the getUserPass method is only returning the values from PHP_AUTH_USER and PHP_AUTH_PW when both are populated but doesn't care about the population of HTTP_AUTHORIZATION. @evert Has this any particular reason?

Anyways, I'll come up with a patch that somehow populates HTTP_AUTHORIZATION on that environment.

LukasReschke · 2015-01-15T18:46:17Z

This is actually caused by PHP-FPM stripping the Authorization header, our .htaccess has a rule for that in place as can be seen at

core/.htaccess

Lines 4 to 7 in 36ced1f

    
           <IfModule mod_headers.c> 
        
           SetEnvIfNoCase ^Authorization$ "(.+)" XAUTHORIZATION=$1 
        
           RequestHeader set XAuthorization %{XAUTHORIZATION}e env=XAUTHORIZATION 
        
           </IfModule>

However, for that to work mod_rewrite has to be installed… – People seems to forget that on a few cases, so we might add an ugly hacky work–around into base.php

This is an unbelievable hacky workaround for #13398, the issue there was that when using PHP-FPM and having either our .htaccess not enabled or mod_rewrite is not enabled no basic auth headers were passed. This failed when a login was tried without a password since SabreDAV only uses credentials in PHP_AUTH_USER and PHP_AUTH_PW when both are not null. In all other cases the Authorization header is decoded. However, PHP-FPM strips it and thus the login failed and S2S was horribly broken.

LukasReschke · 2015-01-15T19:01:08Z

Unbelievable hacky patch: #13403

evert · 2015-01-15T20:04:05Z

Hi Lukas,

That patch should not make a difference. PHP_AUTH_* is used, here:

https://github.com/fruux/sabre-dav/blob/1.8/lib/Sabre/HTTP/BasicAuth.php#L30

LukasReschke · 2015-01-15T20:05:08Z

@evert Yes! - But PHP_AUTH_PW is empty in our case.

LukasReschke · 2015-01-15T20:05:26Z

For server-to-server sharing we just have a long random token as username

evert · 2015-01-15T20:13:01Z

You shouldn't abuse basic oauth for this then :) Just come up with your own scheme:

 Authorization: owncloud-token blabla

However, I guess this could be considered a sabredav bug then. The check for existence of PHP_AUTH_PW should be isset, not a simple boolean check.

LukasReschke · 2015-01-15T20:32:45Z

@schiesbn @DeepDiver1975 Any thoughts about the above? ^

@jnfrmarks

This is a backport of https://github.com/fruux/sabre-dav/issues/596 to the version used by ownCloud. Without this S2S is not working in some server environments. This patch has been confirmed to work by @jnfrmarks. Fixes owncloud/core#13398

DeepDiver1975 · 2015-01-22T12:05:51Z

@schiesbn @DeepDiver1975 Any thoughts about the above? ^

like own token thingy? maybe - relates to many other things (session revokation, token based api access ....) - we shall chat about this at the next meeting

LukasReschke · 2015-01-23T10:45:52Z

Created #13622 to track this

LukasReschke self-assigned this Jan 15, 2015

LukasReschke added this to the 8.0-current milestone Jan 15, 2015

LukasReschke added the Type:Bug label Jan 15, 2015

LukasReschke mentioned this issue Jan 15, 2015

Server to server sharing / webdav auth inconsistency #12585

Closed

LukasReschke mentioned this issue Jan 15, 2015

Create HTTP_Authorization header when none exists #13403

Closed

evert mentioned this issue Jan 15, 2015

Support empty password in basic auth sabre-io/dav#596

Closed

LukasReschke mentioned this issue Jan 19, 2015

Support empty password in basic auth owncloud-archive/3rdparty#151

Merged

MorrisJobke closed this as completed in owncloud-archive/3rdparty#151 Jan 23, 2015

LukasReschke mentioned this issue Jan 23, 2015

Don't abuse basic auth for things we shouldn't #13622

Closed

This was referenced Jan 31, 2015

Maybe folder name causing "400 bad request" error, preventing sync on Win8/8.1/10 #13806

Closed

Call to undefined method OC_Util::isWebDAVWorking() at settings/admin.php#44 #13807

Closed

LukasReschke mentioned this issue Feb 4, 2015

Server2server sharing doesn't work with php-fpm #9416

Closed

ghost mentioned this issue May 13, 2015

Fix for client authentication issues on some webhosts #16312

Closed

ownclouders mentioned this issue May 28, 2018

[Concept] Introduce (Pluggable) Authentication Modules #31546

Closed

10 tasks

lock bot locked as resolved and limited conversation to collaborators Aug 14, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Problem with authentication headers #13398

Problem with authentication headers #13398

LukasReschke commented Jan 15, 2015

LukasReschke commented Jan 15, 2015

LukasReschke commented Jan 15, 2015

LukasReschke commented Jan 15, 2015

LukasReschke commented Jan 15, 2015

LukasReschke commented Jan 15, 2015

evert commented Jan 15, 2015

LukasReschke commented Jan 15, 2015

LukasReschke commented Jan 15, 2015

evert commented Jan 15, 2015

LukasReschke commented Jan 15, 2015

DeepDiver1975 commented Jan 22, 2015

LukasReschke commented Jan 23, 2015

Problem with authentication headers #13398

Problem with authentication headers #13398

Comments

LukasReschke commented Jan 15, 2015

LukasReschke commented Jan 15, 2015

LukasReschke commented Jan 15, 2015

LukasReschke commented Jan 15, 2015

LukasReschke commented Jan 15, 2015

LukasReschke commented Jan 15, 2015

evert commented Jan 15, 2015

LukasReschke commented Jan 15, 2015

LukasReschke commented Jan 15, 2015

evert commented Jan 15, 2015

LukasReschke commented Jan 15, 2015

DeepDiver1975 commented Jan 22, 2015

LukasReschke commented Jan 23, 2015