Web Installer Defaulting to "root" with No Password - Fresh Install

[TomRivers]

Steps to reproduce the issue

Start with a stock Fedora 24 Linux system with the database root user secured with a password. Follow all the instructions for deploying the Joomla_3.6.2-Stable-Full_Package.zip as per the installation/INSTALL document up to the point of opening the Joomla Web Installer in a browser window. Fill in all of the form fields for Step 1 and click Next to advance to Step 2 where the database credentials created for the installation are supposed to be entered. The page will not advance, stays exactly where it is, and no descriptive messages are displayed to indicate the nature of the problem.

After looking at the database logs, an access denied message is recorded for both the POST and the GET requests from the Web Installer showing an attempt to gain access using "root" with no password. This occurs on the initial page load and for the POST and GET requests generated when clicking Next to advance past the start page.

Ample details of the procedure involved, analysis of the log files, and initial debug steps performed are available at the following link: http://forum.joomla.org/viewtopic.php?f=707&t=933022

Expected result

The Web Installer should proceed to Step 2. If not, a meaningful error message should be displayed so the user can take whatever corrective actions are required to fix the issue.

Actual result

The Web Installer stays put at Step 1, does not pass GO, and does not collect $200.

System information (as much as possible)

Stock Fedora 24 Linux server on a physical system in a co-located facility.
Linux 4.6.7-300.fc24.x86_64

Apache RPMs

fedora-logos-httpd-22.0.0-3.fc24.noarch
httpd-2.4.23-4.fc24.x86_64
httpd-filesystem-2.4.23-4.fc24.noarch
httpd-tools-2.4.23-4.fc24.x86_64
libmicrohttpd-0.9.46-2.fc24.x86_64

MariaDB RPMs

mariadb-10.1.16-1.fc24.x86_64
mariadb-common-10.1.16-1.fc24.x86_64
mariadb-config-10.1.16-1.fc24.x86_64
mariadb-errmsg-10.1.16-1.fc24.x86_64
mariadb-libs-10.1.16-1.fc24.x86_64
mariadb-server-10.1.16-1.fc24.x86_64

PHP RPMs

devassistant-dap-php-0.11-3.fc24.noarch
php-5.6.24-2.fc24.x86_64
php-cli-5.6.24-2.fc24.x86_64
php-common-5.6.24-2.fc24.x86_64
php-gd-5.6.24-2.fc24.x86_64
php-mbstring-5.6.24-2.fc24.x86_64
php-mysqlnd-5.6.24-2.fc24.x86_64
php-pdo-5.6.24-2.fc24.x86_64
php-pear-1.10.1-5.fc24.noarch
php-pecl-jsonc-1.3.10-1.fc24.x86_64
php-process-5.6.24-2.fc24.x86_64
php-xml-5.6.24-2.fc24.x86_64

Additional comments

As I detail in the forum post, the installation code defaults to "root" with no password when setting up access to the local MySQL database instance. Since the account has been secured with a password, any attempts to access the database that way will always fail. Since the installation procedure tried to access the database prior to actually prompting for the credentials it needs to access it, the cart has been placed before the horse. Either the installation needs to proceed to the point where valid credentials can be entered, or the database credentials need to be requested in Step 1. In either case, meaningful feedback to the user would be very helpful in the case where the installation cannot proceed.

I would be happy to help in any way I can with crafting a work-around / fix for this issue but I will need some help getting started due to my unfamiliarity with the platform. Feel free to contact me for anything you need.

[Bakual]

Step 1 doesn't write anything to the database for obvious reasons. Simplest test to verify that statement is to shut down MySQL and it will still advance to Step 2. After you fill in the database credentials in Step 2, the installer will try to establish the connection and complain if it fails as expected. It still doesn't write anything to the database at this point.
It's only after Step 3 when you click "Install" that the database tables are generated and the configuration.php is written.

To my knowledge, the data collected in Step 1 and 2 is stored in the user session until the final step.

So it really looks like an issue with your server setting that it for some strange reason tries to access the database.

[Bakual]

Maybe @mbabker has a clue what could cause this?

[brianteeman]

Tom With all respect as an experienced developer you will know that web hosts never configure mysql to work without password and very rarely as a user called root. So how do you think millions of joomla sites were installed if it works the way that you claim.

[mbabker]

The fact it's creating a default instance with these values shouldn't be an issue unless it's actively trying to connect to the database. With that said, a connection does attempt to be opened because of the inner coupling between our filtering API with a database object to determine if Unicode Supplementary Characters should be stripped, but it catches the Exceptions that the database API throws because the credentials are most assuredly invalid at this early point in the installer. At the most this should just cause a notice on the MySQL server side about an invalid connection attempt but not kill the Joomla installer.

Since you say this is failing for you, since the error handling in the install app is sometimes flaky, I'd suggest in the installation/template/js/installation.js file's submitform function, add this line in the AJAX request's fail callback:

console.log(xhr);

And for the sake of completeness, add this to the done function's callback:

console.log(r);

That should at least catch the raw response objects being passed in to try and catch what error is being raised in your environment. The fact it's not proceeding to page 2 most likely means that you're getting a PHP error that's breaking the expected JSON response from the first form submission.

[TomRivers]

@Bakual "Step 1 doesn't write anything to the database for obvious reasons. Simplest test to verify that statement is to shut down MySQL and it will still advance to Step 2. "

It may not write anything to the database, but it certainly tries to access it as root - that is documented in the details of what I posted. Using root as a default user is a security no-no in the first place but yet that is what the code is using.

I shut down the database server and it would not advance to Step 2. The page refreshes but goes nowhere. What would you like me to try next? There are no error messages that say anything of value to help me determine what is happening.

[TomRivers]

@brianteeman "So how do you think millions of joomla sites were installed if it works the way that you claim."

My first thought was that they use a pre-configured configuration.php file of some sort and didn't use the Web Installation Wizard. Since nobody in the forum would help by providing me any information on precisely what Joomla is trying to accomplish in Step 1, all I could do is try to figure it out on my own.

Despite that, the installer is not going anywhere, no messages are being displayed, and I am getting contemporaneous access denied messages in my database logs for the root account. I can always manually configure the package but I wanted to help figure out why the Web Installer isn't working as expected because I like a good challenge and I am not afraid of rolling up my sleeves and pitching in to fix it.

[TomRivers]

@mbabker "I'd suggest in the installation/template/js/installation.js file's submitform function, add this line in the AJAX request's fail callback:"

Thank you very much for the suggestion and for taking the time to explain what's happening. I will make that adjustment and report back.

[brianteeman]

My first thought was that they use a pre-configured configuration.php file of some sort and didn't use the Web Installation Wizard.

Nope probably 80% use the web installer. 10% some one click installer from their web host and perhaps 10% using softaculous

I personally run the installer perhaps 5-10 times every day as part of my cms maintainer role testing bugs and pull requests on my servers none of which are configured to accept root as a username or no password .

[TomRivers]

@mbabker I owe you a drink my friend! The console output commands showed nothing but they pointed me to where I could see what was happening. When I switched on Mozilla's developer tools and looked in the console I was greeted with the following when I clicked Next:

Password fields present on an insecure (http://) page. This is a security risk that allows user login credentials to be stolen.[Learn More]index.php
Use of getAttributeNode() is deprecated. Use getAttribute() instead.

The [Learn More] link points to the following URL: https://developer.mozilla.org/en-US/docs/Web/Security/Insecure_passwords.

Once I enabled SSL on the page, I was able to proceed to Step 2. I am still missing a couple of pre-requisites before I can test to see if the wizard will complete successfully, so I will do that and post back with my results.

It's funny, but I have SSL enabled for only certain directories because this is a development machine and I have been doing some testing with respect to mod_rewrite for another project and the Joomla files were unpacked in a directory that didn't automatically enforce SSL. When I cut and pasted the http://www.example.org text from the installation instructions and swapped in my domain, it didn't activate SSL and I didn't give it a thought because I am connecting to the system using a VPN tunnel so there isn't any risk of traffic being intercepted. I've never seen a form fail in this way before, especially when I saw both a POST and a GET in my Apache logs associated with the submission of the page every time Next was clicked. That's why the access denied messages that I found in my logs got me thinking. Everyone said it doesn't access the database at that stage but it actually does.

I suspect I might not be the only one who might get bit by this. What do you think is the logical next step?

[TomRivers]

On a side note, why is "root" being used at all in the defaults for connecting to the database? I would think that including that in the code, other than to report to the user that their system is not secure, is bad form. I also don't understand why the loading of the Web Installer causes access to the database as well as the POST and GET form clicking Next on Step 1. Is there a specific reason for that?

[brianteeman]

I suspect I might not be the only one who might get bit by this. What do you think is the logical next step?

You're the first we've heard of so far

[TomRivers]

You're the first we've heard of so far

There's always a first. ;) If I took the advice of the non-technical "experts" in the forums I would've given up and worked around it so you would have probably never known. I just don't like computers getting the best of me so I like to dig in and fix things like this.

[mbabker]

Well if browsers are getting to the point where they're blocking form submissions with passwords on plain HTTP connections we are going to have a problem at some point. But nothing in Joomla's code is blocking that.

As for why root? Who knows anymore. There's so much code in Joomla that still resembles how a lot of the structure was written in 2007-2008.

[TomRivers]

Let me be abundantly clear - I am not trying to find a problem and drop it in your collective laps to fix while I walk away and do something else. If there is interest in fixing this, I would be happy to shoulder as much of the burden as possible. I will need a push in the right direction perhaps, but I am willing to roll up my sleeves and get to work.

[mbabker]

Until some point in 2011 it defaulted to an empty user. Why it changed is unclear (it was part of a "super commit" for lack of better terms).

Either way, the fact it's trying to connect at that point is at most annoying as Joomla's going to catch those connection errors and roll on without the connection at that point in the installer, you're just going to get the notices on the database server side if you've got a MySQL instance running and listening on localhost. It's not actually causing any system errors.

[zero-24]

This removes the default root account: #11881

[TomRivers]

A bit of housekeeping: the installation of the site went fine and it is now functioning.

[TomRivers]

Nice zero-24!

[TomRivers]

By the way, I just want to take a moment and thank all of you for taking the time to address this issue. I really appreciate the rapid feedback and the level of technical expertise on display here. You guys are awesome! If I had the chance to work with people of your caliber every day I would be in paradise.

[zero-24]

If I had the chance to work with people of your caliber every day I would be in paradise.

@TomRivers You can join the Joomla Community 😄

Pick up a team you want to contribute contact and the coordinator: https://volunteers.joomla.org/teams

A other way would be you are arround on the Tracker and can fix / report bugs & issues.

[brianteeman]

I am going to close this now as there is nothing left to do