0

Situation

I have implemented a modified version of the kirby Auth plugin on a client website, it basically works this way

  • User accounts are simple kirby content files with the title serving as the login and a password field containing a bcrypt encrypted version of the users password
  • On the website, visitors can click on "Customer Area", which goes to a template managed by the modified auth plugin (which redirects to the "login" form).
  • The website is multilingual. So the accounts file will look like content/extranet/login/login.fr.txt or as an example content/extranet/bastian/bastian.fr.txt, this is what the modified Auth plugin is looking for, it finds the file and reads it, checks the password, and the logins the users.
  • This system requires account pages title to be the same as their URL, and to always be invisible pages
  • User is logged in and can only see in the « secure » template the files present in his folder

This all works good here on my local MAMP server as you can see in the screenshots, but on the production server http://www.driving-evolution.com, this doesn’t work, and i don’t know why, i have looked in a lot of places and i don’t understand what is going on. (it doesn’t work on the staging server either)

On the production server, wether you enter a good or a bad login, the form doesn’t show any error message, and doesn’t log the user in either. At first i thought this is maybe because of my bcrypt install, but it is not, as i disabled it (and used plain passwords instead) and it still didn’t work.

The issue seems NOT to be from the plugin here but from a difference between my live PHP stack and local php stack (my guess is on the php session handling).

Remote PHP is 5.3.3

Here is a sample output of CURL on both installations :

WORKING (Local)

curl -d "username=test&password=test" -i devo.loc/fr/login

HTTP/1.1 302 Found
Date: Tue, 27 May 2014 12:59:49 GMT
Server: Apache/2.2.25 (Unix) mod_ssl/2.2.25 OpenSSL/0.9.8y DAV/2 PHP/5.5.3
X-Powered-By: PHP/5.5.3
Set-Cookie: PHPSESSID=9249a942248a2382d8eb10090bf5d825; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Set-Cookie: authFrontend=mc06csp25; expires=Wed, 28-May-2014 12:59:49 GMT; Max-Age=86400; path=/
Set-Cookie: PHPSESSID=b38ec0b342356c2c38778e4a6925f085; path=/
Set-Cookie: authFrontend=8qyyn; expires=Wed, 28-May-2014 12:59:49 GMT; Max-Age=86400; path=/
Location: http://devo.loc/fr/extranet
X-UA-Compatible: IE=edge
Vary: Accept-Encoding
Content-Length: 0
Content-Type: text/html; charset=utf-8

FAILING (Remote)

curl -d "username=test&password=test" -i www.driving-evolution.com/fr/login

HTTP/1.1 200 OK
Date: Tue, 27 May 2014 13:01:32 GMT
Server: Apache
X-Powered-By: PHP/5.3.3
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Set-Cookie: PHPSESSID=6j9o1i4djetojtbg444i51efm7; path=/
Vary: Accept-Encoding
X-UA-Compatible: IE=edge
Connection: Keep-Alive, close
Transfer-Encoding: chunked
Content-Type: text/html

USEFUL LINKS

REMOTE PHPVER : http://www.driving-evolution.com/phpver.php

SCREENSHOTS when it works on local

login-good login-done

Hope someone will be able to help me on this ! Ask for any further info and i will give it.

Wilhearts
  • 169
  • 1
  • 1
  • 6

1 Answers1

0

Turns out it WAS a problem with the CMS, file caching was turned on and not ignoring the "login", "logout", and "extranet" files (all related to customer area), had to add :

c::set('cache.ignore', array('api', 'sitemap', 'extranet', 'account', 'login', 'logout'));

to my kirby config (api and sitemap are unrelated).

This fixes the problem as the login form was cached and thus not hitting anything on the server. Now form is not cached.

Wilhearts
  • 169
  • 1
  • 1
  • 6