Endless redirects or user doesn't exist with basic authentication

[HeikoWolf]

I'm trying poche (1.3.0) the first time. Basic setup was straight forward and works in my LAN, but if I try to access my installation from outside, which requires a basic authentication from my web server (lighttpd), it didn't work.

At first, I got the message "login failed: user doesn't exist" – but I haven't entered login and password yet! If I use the same login and password for basic authentication (web server) and poche, I get an endless redirect.

I asked for help in irc, user cryptosteve confirmed this bug immediately. We both use lighttpd, I use Debian Squeeze, he is using Gentoo.

[nicosomb]

Hello @HeikoWolf !
Unfortunately, I can't reproduce this bug (no lighttpd server).

If someone can help us ...

[aaa2000]

It is not linked to lighttpd server, I use apache and I had the same problem.

It seems that you should put "php_auth" as password on the poche configuration page when you use an basic authentication.

[pr0j3ctx]

Same Problem here. If I moved .htaccess files. All working nice.

Where should I put "php_auth"?

[nicosomb]

.htaccess file? which one?

[pr0j3ctx]

I had .htaccess .htpasswd in /var/www/ for Authentication.
If I moved this file to disable this Authentication, poche works fine.

How will It work with this Authentication?

[aaa2000]

You should copy again install/poche.sqlite in db/ to see the poche configuration page. I don't know if there is an other way to see it. In the configuration, you enter the username and "php_auth" in the paswword input.

But, because of basic authentification, you will have an another problem #390 "Empty article title and content (blank title tag and content)" when you poche a link.

[nicosomb]

what is your webserver configuration?

[aaa2000]

In my virtual host, I have this configuration

<Directory /var/www/poche>
    AuthType Basic
    AuthName "Secure Content"
    AuthBasicProvider file
    AuthUserFile /etc/apache2/passwords
    Require valid-user
</Directory>

[mariroz]

this error appears by me too (wallabag-1.3.1, Apache web server).
I investigated it a little.
Let me explain what is wrong.
Once you install poche, you create user with encoded password string "$password . $login . SALT", where password is real password, entered by you.
BUT, let see what happens once you will try to login:
index.php recognise $_SERVER['PHP_AUTH_USER'] line 94, then if user does NOT exists, all is ok and "user not exists" message is shown, but if user exists in users table, then poche tries to login it: line 676 in Poche.class.php. Here first of all it gets credentials from method just above login method. It returns correct user name BUT password is "php_auth" and then poche tries to find user with password string "php_auth . $login . SALT" and, of course, can't find it. And here the loop begins.
So, to fix this error, you have don't check password for http authenticated users.

[nicosomb]

Is there anyone who can try to fix it?

[mariroz]

will try to get more familiar with your code and will try to fix.

[nicosomb]

@HeikoWolf @aaa2000 @pr0j3ctx @mariroz Can you test dev branch please? https://github.com/wallabag/wallabag/tree/dev

[Faless]

It works with the dev branch if the user name is the same of the https auth (password doesn't matter).
It keeps saying "login failed: user doesn't exist" (but no endless redirect) if the wallabag user has a different name from the https auth.

[nicosomb]

So can you confirm it's good for you?

[Faless]

Yes, I can confirm that if the http auth user name matches the wallabag user name everything works fine (I can login and so on).

On the other side, If the wallabag user name is different from the http auth user name it says "login failed: user doesn't exist". If that is the intended behaviour than everything is fine.

[mariroz]

I, of course, can confirm, that it works by me too.
And, yes, it is an intended behaviour to auto authorise http auth user if username exists in db (like in some other products, for example dokuwiki works in the same manner).

[nicosomb]

@mariroz and @Faless : can you tell me if these issues are fixed too: #396 #390 #389 and #366 ?

[Faless]

Yes, the blank article bug is gone.
I removed the workaround I had in my apache config and it keeps working.
So I can confirm #396 #390 #389 and #366 are fixed for me.

Thanks for the great work!

[mariroz]

@nicosomb , except of #389, I think, that other mentioned issues may be related to current (personally I havn't seen it all, so can't confirm they are gone).

[nicosomb]

#389 is fixed.
So, all bugs are fixed!