If you don't know Anuko TimeTracker, and you are looking for a good web-based time tracking application that you can install on premise (i.e. without getting poor by paying a monthly fee to Timely, Wrike and the likes), you should definitely give it a try: Anuko Time Tracker is a simple, easy to use, open source, web-based time tracking application written in PHP that allows you to track the time that employees, colleagues, or teammates spend working on projects and tasks. It needs a web server such as Apache, IIS, etc. to run on, and a database to keep the data in, such as MariaDB or MySQL.
Before proceeding, it's worth noting that we are not affiliated to Anuko in any way: we just love the software and use it a lot, and also suggest it to all our client and customers that manifest the aforementioned requirements. We also developed a custom mod to allow an Excel export (CSV-based, but it works!) for the timesheet, which we'll be talking about in a upcoming post.
The Problem
Despite its greatness, Anuko has a small yet nasty issue: its login / auth implementation is quite convoluted and tends to give opaque signs - or, to better say that, no signs at all - whenever there are authentication issues. When this happens, you will often experience the login page reloading itself with no apparent reason: you type the (correct) username and password, hit login and get the reload, without significant errors.
That's quite frustrating, isn't it?
Luckily enough, we got such issue covered. Before giving out the actual solution, let's try to understand what happens under the hood.
The issue is caused by an odd behaviour within the ttAccessAllowed function, which is declared in the WEB-INF/lib/common.lib.php page (line 372 or so): if you look there, you'll see that there is a hard redirect to the login page if the $auth->isAuthenticated() method returns FALSE. This is what actually happens:
- The user gets firstly redirected to the login.php page (see above screenshot), where he can fill up the login form by typing its username and password.
- The user types the credentials and hit the Login button, thus issuing a POST request.
- The application gets the POST request and, after a small bunch of high-level checks, will redirect the request to one of the starting pages, depending on the user's rights: for example, if the authenticating user is a standard user, it will be sent to the time.php page.
- The time.php page calls the ttAccessAllowed function to ensure that the authenticated user has the proper rights to access its content... and there goes the issue! The ttAccessAllowed function calls the $auth->isAuthenticated() method, which returns FALSE, and therefore redirects the user to the login.php page: since the login page gets reloaded from scratch, being at the end of a request redirect cycle, it won't be showing any error message, warning or anything else.
Now, the fact that we're getting no significative error message is, at least partly, a PHP/HTTP design issue: however, the real culprit - which causes the $auth->isAuthenticated() method to return FALSE - often lies elsewhere: let's see where.
The Solution
The causes of this problem are almost always related to a wrong configuration of the PHP session folder - the FileSystem directory where PHP stores the session files. Most of the times we're talking of permission issues: more specifically, the session folder must be owned by the PHP process owner, i.e. the one specified in the relevant PHP configuration files, depending on the PHP implementation used by the web server:
- for mod_php, see /etc/httpd/conf.d/php.conf
- for php-fpm, see /etc/php-fpm.d/*.conf
The session folder is defined by the session.save_path setting within the php.ini file, and it's usually /var/lib/php/session/; however, just to be sure, it can be easily checked by performing the following steps:
- Create a phpinfo.php file in the Anuko TimeTracker folder;
- Fill it with the following PHP code one-liner: <?php echo phpinfo (); ?>
- Open a web browser and navigate to that page. You will be able to see the php.ini file path and the session.save_path setting value in a single shot.
Once you've successfully determined where the path actually is, you can go there and change the relevant permissions by setting the owner and the group accordingly. As soon as you do that, your issue should be fixed: PHP will be able to create its session files, and you'll be able to login to Anuko Time Tracker again!
Conclusion
That's it, at least for now: we sincerely hope that this post will help other system administrators and/or php developers struggling to make their web application login page working again. See you next time, and... happy tracking!
