oc-164 - unable to login to webdav on sharehoster all-inkl.com with php-cgi

[msrex]

From http://bugs.owncloud.org/thebuggenie/owncloud/issues/oc-164

Unclear whether this is fixed. Reporter still active - see comments.

Description:
At least at the sharehoster all-inkl.com it is impossible to login to /files/webdav.php. Opening the url in a browser brings up the login window again and again.

On my webspace php 5.3 is available only as cgi. I tracked the issue down to the variable HTTP_AUTHORIZATION not working in my environment. After switching to REMOTE_USER it works like a charm.

Changes I made:

1. .htaccess: Change Rewrite Rule to

RewriteRule .* - [env=REMOTE_USER:%{HTTP:Authorization},last]

1. lib/base.php: As my REMOTE_USER also seems to get prefixed a REMOTE I added the following after line 126:

if (isset($_SERVER['REDIRECT_REMOTE_USER']) && preg_match('/Basic\s+(.*)$/i', $_SERVER['REDIRECT_REMOTE_USER'], $matches))
{
list($name, $password) = explode(':', base64_decode($matches[1]));
$_SERVER['PHP_AUTH_USER'] = strip_tags($name);
$_SERVER['PHP_AUTH_PW'] = strip_tags($password);
}

HTH

Lars

Reproduction steps:

1. Install owncloud 3 with an account from all-inkl.com
2. Try to access webdav url owncloud.url/files/webdav.php in a browser
3. Login window pops up over and over again no matter what you enter.
4. Cancel leads to the following error:

<d:error>
<s:exception>Sabre_DAV_Exception_NotAuthenticated/s:exception
<s:message>No basic authentication headers were found/s:message
<s:sabredav-version>1.5.4/s:sabredav-version
/d:error
#2 Comment posted by Wromey Feb 01, 12:50

On my webspace php 5.3 is available only as cgi.

Does that mean, owncloud does not recognize php 5.3. Can this be the reason, that the gallery is not working for me?

Wolfgang
#3 Comment posted by lars Feb 01, 14:12

@Wromey: No, that means that the version of mod_php is prior to 5.3 but other versions are available as php-cgi. You can tell apache to use them in .htaccess. At my hoster the needed line is

AddHandler php53-cgi .php

Lars
#4 Comment posted by Wromey Feb 02, 10:48

That solved the most problems for me: the Calendar is shown, gallery is working in iceweasel and konqueror, bookmarks are saved..

Thanx

Wolfgang
#5 Comment posted by Georg Ehrke Mar 23, 16:02

Wolfgang: are only the apps fixed or also the webdav problem?
#6 Comment posted by ahahn Apr 16, 21:18

I have the same Issues with my Web Dav login. I´m hosting Own Cloud on my own Server (WebServer2008 R2). I did the changes you advised, but I still have the same trouble with the login via Web Dav smileys/4.png
#7 Comment posted by Patrick Jun 02, 17:42

This solved my problem for logging in with Web DAV.
#8 Comment posted by Robin Appelman Sep 30, 01:54

Can anyone confirm if the problem still exists with the latest test release?
#9 Comment posted by miška Nov 07, 15:44

I can confirm this. Was helping out during local conference one guy to setup ownCloud on his web hosting. It was ownCloud 4.5.1a and we still hit the same bug (fortunately patch worked). Again it was some generic hosting provider - nothing in provided logs, no idea about technical background of the hosting and no way to reproduce it now as I'll probably never meet that guy again.

[altima]

I added some code toe the basicauth file in sabre dav (BasicAuth.php in "3rdparty/Sabre/HTTP/"):

if (!$auth) {
            $auth = $this->httpRequest->getRawServerValue('REMOTE_USER');
        }       
        if (!$auth) {
            $auth = $this->httpRequest->getRawServerValue('REDIRECT_REMOTE_USER');
    }

and changed the .htaccess rewrite rule from

RewriteRule .* - [env=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

to

RewriteRule .* - [E=REMOTE_USER:%{HTTP:Authorization},L]

with this change, the login is possible (web,dav,iphone - tested)

[BernhardPosselt]

@altima Please create a pull request, just posting some code wont help anyone ;)

[nerdiges]

Just want to confirm, that issue still exists in version 5.0.6

Altima's solutions still works in OC 5.0.6.

Would be nice if this would be included in the next version.

Cheers

[jancborchardt]

I’m closing this issue because it has been inactive for a few months. This probably means that the issue is not reproducible or it has been fixed in a newer version.

Please reopen if you still encounter this issue with the latest stable version (currently ownCloud 5.0.9) and then please use the issue template. You an also contribute directly by providing a patch – see the developer manual. :)

Thank you!

[nikogh]

The problem is still there, owncloud is not compatible with PHP in Fast-CGI Mode.

[PVince81]

Is this still an issue with OC 6.0.4 or OC 7.0.1 ?
From what I read recently people seemed to have no issues with Fast-CGI

[nikogh]

Sorry, I can not test it anymore, because I solved the problem by replacing php in fast-cgi mode.

[PVince81]

Thanks for the info.
Since this is a bug from OC 5 I'm closing this.

If anyone is still having issues with OC 6.0.4 or OC 7.0.1, feel free to reopen.

[stefan-muc]

This bug is still valid for OC 7.0.4 with PHP 5.3 as cgi module.

This both lines fixed it for me:
.htaccess

RewriteRule .* - [env=REMOTE_USER:%{HTTP:Authorization}]

/3rdparty/sabre/dav/lib/Sabre/HTTP/BasicAuth.php add this line before if (!$auth) return false;

if (!$auth) {
    $auth = $this->httpRequest->getRawServerValue('REDIRECT_REMOTE_USER');
}

Please reopen this issue. I don't know how I can do this.

[MorrisJobke]

I will create a PR for those changes.

[MorrisJobke]

@stefan-muc Can you explain what the following does?

RewriteRule .* - [env=REMOTE_USER:%{HTTP:Authorization}]

It should simply put in the content of HTTP:Authorization into the env variable REMOTE_USER

This is already done in .htaccess via

RewriteRule .* - [env=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

The only difference I see is the name of the env variable. Is that the crucial part or why is this needed?

[MorrisJobke]

The name change seems to be related to how mod_php and cgi named them.

As the second change is in the Sabre/DAV 3rdparty library, I would like to not patch it, but to provide a patch upstream.

@evert Should I provide a PR for this, or is there another way to handle the auth headers in CGI mode?

[evert]

It doesn't make sense for me to integrate a patch specifically for the people that manually chose to use REMOTE_USER for this instead of HTTP_AUTHORIZATION, which is what's recommended.

REMOTE_USER shouldn't really be used for this. It's a different environment variable that typically holds just a user name.

[MorrisJobke]

@evert Makes sense.

@stefan-muc Why isn't the env variable working for cgi, do you have any idea or log message?

[stefan-muc]

@MorrisJobke If I install OC on a PHP cgi server and want to access WebDAV with a browser (for testing) the HTTP login window appears over and over - no matter if I provide wrong or right credentials. So I searched the net for a solution, and http://klein-gedruckt.de/2013/01/owncloud-bei-all-inkl/ told me that I have to change those two lines - and then it worked. Didn't have time to track it down further, but I'm willing to help as much as I can.

For testing I made a new webspace account and set up a .htaccess "AuthType Basic" authentication, which should be the same type of authentication OC uses for WebDAV

I included following lines in the .htaccess:

RewriteEngine On
RewriteRule .* - [env=DEBUG_HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteRule .* - [env=DEBUG_SET_VARIABLE:value]

Here are the result phpinfo() with this configuration:
http://w012c2d0.dd26228.kasserver.com/auth/infophp.php (PHP 5.2 module)
http://w012c2d0.dd26228.kasserver.com/auth/infophp.php4 (PHP 4 cgi)
http://w012c2d0.dd26228.kasserver.com/auth/infophp.php52 (PHP 5.2 cgi)
http://w012c2d0.dd26228.kasserver.com/auth/infophp.php53 (PHP 5.3 cgi)

So as far as I can see, mod_rewrite is unable to set the environment variables in a php cgi environment. So changing the line in .htaccess is useless, the changing of /3rdparty/sabre/dav/lib/Sabre/HTTP/BasicAuth.php is the one that really enabled the authentication.

[evert]

If REMOTE_USER worked for you, then DEBUG_HTTP_AUTHORIZATION should as well...

I can't really see the result of the 4 pages you posted though, as they require a username and password.

[stefan-muc]

Just carefully read the message box asking you for username and password. Both is written there :)

[evert]

Missed that!

Pretty crazy that you're running 4 distinct PHP version, but not a single one that's not end of life :P

I just checked 5.3. It's odd that the DEBUG_HTTP_AUTHORIZATION header does not show up. There's two possibly explanations:

1. Because you let apache do the authentication, apache refuses to expose the information in the Authorization header.
2. You have some kind of custom setting going on to prevent this from working.

It would be good if you could test for 1 is correct. The easiest way to do this, is to create a script such as this:

<?php

     header('WWW-Authenticate: Basic realm="foobar"');
     phpinfo();

?>

And remove the apache authentication configuration. Note that that PHP script never stop asking for a username and password, but that's ok. Just fill in a completely random username and password once, and then hit escape to see the result of phpinfo().

[tmciver]

I spoke with @stefan-muc in #owncloud-dev (IRC) about a similar problem I had run into and he asked me to post my information here as well. I use Webfaction for hosting and had an authorization problem involving environment variables that was ultimately solved by following the instructions found here: http://www.blaicher.com/2012/07/fixing-authentication-of-owncloud-for-webfaction.

My server lists the server API as "CGI/FastCGI".

[stefan-muc]

@evert Here you go:
http://w012c2d0.dd26228.kasserver.com/evert/infophp.php
http://w012c2d0.dd26228.kasserver.com/evert/infophp.php4
http://w012c2d0.dd26228.kasserver.com/evert/infophp.php52
http://w012c2d0.dd26228.kasserver.com/evert/infophp.php53

For 2: nothing custom that I did - that's the webspace as I get it from all-inkl.com
Really, all php versions are end of line? That's not what I'm paying them for, so I guess I definately have to talk with them ^^ Yes, PHP 5.4 would be nice for the news app, I didn't get that running on my server.

[LukasReschke]

http://php.net/eol.php
http://blog.ircmaxell.com/2014/12/php-install-statistics.html

Gets even more funnier with distributions that decide to support 5.3 or so on their own and backport security patches. Hell, they miss A LOT of security patches… - Our installer had even some vulnerability check for a vulnerability to force RHEL to finally fix it ;-)
(took them only 4 years after initial bug fix to fix it in their version as well)

[jancborchardt]

(Off-topic: @stefan-muc since you live in Munich you should come to our Munich ownCloud meetups :)

[evert]

@stefan-muc if you're saying that that the mod_rewrite regular expression rule is in place, there's no reason why the Authorization string should not end up in the environment.

This is normally always the solution for cgi/fastcgi-based PHP on apache, so I'm going to guess it's your host doing something unusual here. Definitely contact them and see what they say.

Piggybacking on REMOTE_USER just doesn't make sense. It might work for you specifically, but who's to say that some other host is going to prevent that from working as well? It wouldn't make sense for sabre/dav to integrate a patch that specificcally works around poor configuration from 'kasserver.com', which appears to be a pretty poor host to begin with, given that they run such old, insecure software.

Regardless I would be curious to find out what configuration may have caused this behavior.

[nikogh]

@stefan-muc: Please keep me informed about the all-inkl.com answer, I am using their webspace as well and I am shocked and surprised, that their webspace is not state of the art :(

[nikogh]

My all-inkl webspace is running 5.4.34 (Okt14). It is not end of line, although it is not the newest version of this series 5.4.36 (Dec14). Since there are no security issues in the new monthly released versions I feel quite comfortable again.
@stefan-muc: For newer php versions just call or email all-inkl. It will be installed until tomorrow usually.

[stefan-muc]

@nikogh: I have access to another webhosting account at all-inkl which costs lot less than my account, and there they have PHP 5.6 installed. So I guess I will have to mail them - but I will do this next week as for such a great step I will have to check all my scripts for compatibility.
I will definately ask them, why they don't provide me with the newest versions automatically.

[mfechner]

I got the problem fixed by adding to my virtual host definition in apache the following line:

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

[DeepDiver1975]

Any new issues should be opened as new tickets in here - THX