Support

Admin Tools

#19010 Backend log out doesn't work after setting Administrator secret URL parameter

Posted in ‘Admin Tools for Joomla! 4 & 5’
This is a public ticket

Everybody will be able to see its contents. Do not include usernames, passwords or any other sensitive information.

Environment Information

Joomla! version
n/a
PHP version
n/a
Admin Tools version
n/a

Latest post by nicholas on Wednesday, 05 February 2014 13:14 CST

the gorilla
Hello Nicholas, I have been using Administrator secret URL parameter in the Akeeba WAF for a couple of years without any problems. I have recently updated Joomla 3.2.0 > 3.2.1 and Akeeba Tools 2.5.8 > 2.6.0.

Since the update, I am unable to logout of the administrator backend properly. The session is not closed and I am referred to a blank screen. If I remove the secret URL parameter, the site backend closes as expected. I can force the issue by using Purge Sessions, which, by the way, purges all sessions including the current administrator session. (It's possible that Purge Sessions is not currently WAD as it has the same effect of purging ALL sessions on the websites I am currently working on).

nicholas
Akeeba Staff
Manager
Let's make sure that the problem is indeed caused by Admin Tools. In order to do so, try the following:

1. Try setting the Error Reporting level in your Global Configuration to "None". Many errors are caused by harmless PHP Notices and Warnings being output to the browser, breaking anything which requires HTTP header manipulation such as Joomla!'s session management, AJAX calls and download systems.

2. Try to replicate the issue after disabling the "System - Admin Tools" plugin. If you can still replicate the issue, it is not caused by Admin Tools. Disabling that plugin means that Admin Tools code (including the Web Application Firewall) is not running on your site.

3. If you suspect an issue with the .htaccess file, replace its contents with the contents of the stock htaccess.txt file shipped with every version of Joomla!. If you are on GoDaddy please wait for 1-30 minutes for the changes to be effective. Then, retry loading the problem page. If you can still reproduce the error, then it is not caused by .htaccess Maker.

If doing any of the above resulted in the issue still occurring, it's not related with Admin Tools and we can't help you. If doing any of the above did stop the issue from occurring, we'll have to do some troubleshooting.

First go to Admin Tools, Web Application Firewall, Configure WAF. Make sure "Log security exceptions" is set to Yes; if it's not, set it to Yes and click on Save. Now try reproducing your issue. Immediately after that, please go to Admin Tools, Web Application Firewall, Security Exceptions Log. The latest log entry at the top should have the date and time of when the issue occurred. Please copy the Reason and Target URL here so that we can further help you.

If, however, you do not see a log entry, or the Date and/or IP address do not match your last access, this problem is not caused by Admin Tools' WAF. In this case, you will have to do some .htaccess troubleshooting. You may need to read the general .htaccess troubleshooting page, as well as the page on finding out necessary .htaccess exceptions.

Nicholas K. Dionysopoulos

Lead Developer and Director

πŸ‡¬πŸ‡·Greek: native πŸ‡¬πŸ‡§English: excellent πŸ‡«πŸ‡·French: basic β€’ πŸ• My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

the gorilla
Hi Nicholas,

Test results in the order you set them above:-

1) Error report- None. No change to unexpected Akeeba Tools session management behaviour.

2) System - admin tools=disabled. Behaviour reverts to Joomla session management. Works as designed.

3.a) Replaced .htaccess with default Joomla .htaccess file. Front end error 500. Backend no change to unexpected Akeeba Tools session management behaviour.

3.b) Replaced .htaccess with Akeeba Tools htaccess generated file. No change to unexpected Akeeba Tools session management behaviour.

Worth noting that I am using JVitals ExtendedReg also, and the latest Joomla updates have caused unstable session management with that extension which are not yet fully resolved.

Chris

nicholas
Akeeba Staff
Manager
All right, we'll have to debug the white page you get when you try to log out. I believe that this is why the session remains open and I have reasons to believe that it's caused by some third party software. You see, a white page or a page with a 500 Internal Server Error is, in fact, either a .htaccess issue to a PHP fatal error in disguise. We need to know what this error is before we can help you.

First, check your server's error logs (not the access logs) immediately after visiting the page which throws the error. There should be an exact description of the PHP fatal error which occurred. Sometimes you can find the error messages in files called error_log or error.log inside the site's root and/or administrator directories. If unsure about the error log location, please consult your host. Most likely the error logs are available in your site's cPanel, Plesk control panel or similar hosting account management facility.

If your host does not give you access to the error logs and you have access to the Joomla! administrator area, please log in to your site's back-end, go to Global Configuration, click on the Server tab and set the Error Reporting to Maximum (Joomla! 1.5) or Development (Joomla! 2.x and later). Try visiting the problem page again.

If you still get a blank page, edit your configuration.php file and put the following code right after the final closing curly brace ( this is what a curly brace looks like --> } ) but before the closing PHP tag (it looks like ?> that is a question mark and a greater-than sign):
ini_set( 'display_errors', true );
error_reporting( E_ALL ); 
Try visiting the problem page again.

If you still get a white page, please remote the two lines from your configuration.php file. Edit the .htaccess file in your site's root. If you don't have a file named .htaccess create a new one. Beware that htaccess.txt is a DIFFERENT FILE and will NOT work! Add the following to the end of the file:
php_flag display_errors On
php_value error_reporting 32767
and retry loading the problem page.

If you still get a white page, remove the two lines from your .htaccess file. Now, create a file called php.ini with the following content:
display_errors=on
error_reporting=E_ALL
and upload it into your site's root and your site's administrator directory. Retry loading the problem page.

IMPORTANT: Sometimes the error won't show. Edit your configuration.php and find the line starting with public $error_reporting and set it to:
public $error_reporting = 'development';

This instructs Joomla! to enable maximum error, warnings and notices verbosity. In 99.9% of cases it will result in the error messages being shown on the browser.

Please note that if you can not understand what the PHP error message means, just copy and paste it here verbatim so that we can take a look and point you to the right direction.

Nicholas K. Dionysopoulos

Lead Developer and Director

πŸ‡¬πŸ‡·Greek: native πŸ‡¬πŸ‡§English: excellent πŸ‡«πŸ‡·French: basic β€’ πŸ• My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

the gorilla
Nicholas,

I am unable to get access to the server error logs through the host service control panel (1and1 hosting).

1. There are no files in the site root or /administrator called error_log or error.log.
2. Joomla error reporting set to Development.
3. Edited configuration.php as requested. No client error message generated.
4. Configuration.php switch set public $error_reporting = 'development';
5. Edited .htaccess as requested. No client error message generated.
6. Edited php.ini as requested. No client error message generated.


Not the result you were expecting. Blank page still being thrown.

Chris



nicholas
Akeeba Staff
Manager
You will have to ask your host to assist you in retrieving the error message. The white page is something causing a PHP fatal error. If we don't have the error message we'll have to resort to "shotgun debugging": try disabling system plugins one by one, hoping that you'll find the one plugin that gets in the way.

Nicholas K. Dionysopoulos

Lead Developer and Director

πŸ‡¬πŸ‡·Greek: native πŸ‡¬πŸ‡§English: excellent πŸ‡«πŸ‡·French: basic β€’ πŸ• My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

the gorilla
Thanks Nicholas. I requested support on this from my host, 1and1, over a day ago and again 4 hours ago. I'll get back to you.

the gorilla
I have discovered that this issue is an ACL issue with JVitals ExtendedReg. Normal Joomla Tools session management can be restored by disabling ExtendedReg - User and enabling User – Joomla.

I guess case closed as far as Akeeba is concerned.

Thanks so much for the support.

Chris


nicholas
Akeeba Staff
Manager
You're welcome, Chris.

Nicholas K. Dionysopoulos

Lead Developer and Director

πŸ‡¬πŸ‡·Greek: native πŸ‡¬πŸ‡§English: excellent πŸ‡«πŸ‡·French: basic β€’ πŸ• My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Support Information

Working hours: We are open Monday to Friday, 9am to 7pm Cyprus timezone (EET / EEST). Support is provided by the same developers writing the software, all of which live in Europe. You can still file tickets outside of our working hours, but we cannot respond to them until we're back at the office.

Support policy: We would like to kindly inform you that when using our support you have already agreed to the Support Policy which is part of our Terms of Service. Thank you for your understanding and for helping us help you!