FTP connection not working

[jfha73]

Steps to reproduce the issue

Have a user that has a password that contains the symbol @ in your system
Configure that user to be your FTP user in Joomla
Test the connection

Expected result

Connect

Actual result

No connection

System information (as much as possible)

I believe it is because Joomla is using ftp_connect($user:$password@$server); because the password contains @ in it the string will contain 2 @ and will not connect, when it should be something like this:

$conn = ftp_connect($server);
ftp_login($conn, $user, $password);

As I just created that same script and ran it without a problem on my test box.

Additional comments

[jfha73]

I think it would be even better if Joomla allows SSH along with FTP.

Thanks.

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/19960.}

[zero-24]

Why at all do you need to set a ftp user? If this is required please contact your host as this would be a broken server configuration ;-)
You only need this setting if the user that runs php is not the same user that owns the files it self. This is known as wwwrun problem and a hoster configuration problem.

So please only use this feature if you can't get your hoster to configure your webspace correct and you can't move to another hosting provider.

Also this is the reaseon we don't offer ssh as this has nothing todo with ssh or similiar just a broken server setup.

This does not mean we can't fix this issue but to fix all understanding problems beforehand. ;-)

[jfha73]

If you think this is a server misconfiguration, then most (if not all) hosting companies are misconfigured, as I have installed Joomla in quite a few hosting servers along with other CMS like Drupal and Wordpress and in all cases when somebody tries to ftp the server using one line in PHP.

ftp_connect($user:$password@$server)

And the password contains an @, the connection will always fail (I even tested it on my own local Linux server) but when you do it using:

$conn=ftp_connect($server)
ftp_login($conn, $user, $password)

That will work with a password that contains an @ in it.

I'm only trying to help you here guys, I just suggested SSH, because other CMS, like Drupal and Wordpress do have it and it works better when the user password has an @ in it.

[brianteeman]

The comment of @zero-24 was to determine why you even need to use the ftp connection at all, it was not about the @ character.

There really should never be any need to use ftp with joomla ever.

[jfha73]

I'm talking about when you need to update/upgrade Joomla or its plugins, from the administrator side of Joomla.

[brianteeman]

again - you should never ever need to use ftp for that at all. That shows a poorly configured server. It is because of that poorly configured server that we have the ftp option and it might even be removed from future releases.

[jfha73]

OK if that's what you say, it's no wonder my clients are moving to other CMS for their sites.

Also, if it's a poorly configured server, then all hosting companies have poorly configured servers, because I have seen this everywhere.

[mbabker]

If you have to use the FTP layer that's usually indicative that PHP and the web server are configured in a way where the PHP process cannot interact with the filesystem (PHP runs under an incorrect server-side user account as an example). That's the server misconfiguration we're talking about.

So instead of being able to use PHP's native file_put_contents() to write to a file (efficient, it's local filesystem I/O, not as resource heavy as the alternative), Joomla can be configured so that filesystem write operations use an FTP connection (not as efficient, requires opening another network connection, even if it is on the same server, loosely similar to needing a network connection to talk to your database even though it resides on the same server).

I won't say never, but in the overwhelming majority of cases, you should not need to enable Joomla's FTP layer and when it is needed that should raise a red flag that there is a server misconfiguration which prevents PHP from interacting natively with the filesystem.

[brianteeman]

You are correct that it's a bug if the @ is rejected. We were just trying to determine why you are using FTP when you should never need to. the poor configuration comment was nothing to do with the @ symbol and everything to do with a correctly configured server not requiring you to use FTP to update or install anything.

[jfha73]

Most hosting companies use FTP/SSH to allow users to upload files to their sites and they owners of those folders is the user him/her self, not www or wwwrun, therefore FTP/SSH is required to update their sites, yeah, if the owner of the server is the owner of the site, they would be able to change the owner of the site to www or wwwrun in order for FTP/SSH not to be used, but not everybody has that.

I'm closing this now, if you want to fix it, it's up to you.

[brianteeman]

Welcome to 2018

[mbabker]

If you keep closing the issue it won't be fixed because there won't be an open issue tracking this bug.

Most hosting companies use FTP/SSH to allow users to upload files to their sites and they owners of those folders is the user him/her self

You and I have a different experience with hosting companies then. Every shared hosting provider I work with is set up in WHM/cPanel so that the cPanel account is who owns the files and who Apache/PHP are run as, preventing the need for the FTP layer. Say my cPanel username is "mbabker", that is the account I would use for FTP and SSH access to the server, that is the user account who owns the filesystem resources, and that is the user account which server processes run under.

If you're on a shared hosting provider where this isn't the case, that's worrisome. Not only because of the configuration issues, but if you've got multiple sites on a server all running under a www, www-data, or whatever server level account, this potentially means the various accounts and websites aren't being properly "jailshelled" and makes it pretty easy to compromise every site on the server if I can compromise one site (PHP's running as www, I manage to upload a script that can get me the configuration.php and wp-config.php files of every account in the /home directory, and that's going to be a bad day for a lot of people).

[jfha73]

It's not the hosting companies, but the clients, they claim that uploading files with cPanel takes too long and rather use a FTP client or use the CMS itself to update their sites.

[brianteeman]

As repeatedly stated you do not need to use FTP if you are using the CMS to update the sites. I am reopening AGAIN so that the valid issue can be fixed. If you close it again then we will need to take further action to prevent that from happening.

[mbabker]

It's still a hosting company issue. If you're using the CMS to update itself and MUST turn on the CMS' FTP layer, this is indicative of configuration issues. If the clients are insisting that FTP be enabled just because, and the environment does not require it be enabled, then it needs to be explained to the client why this isn't required and the option should be left off.

The CMS is updating itself through PHP function calls and being able to use PHP's native filesystem read/write operations is going to be faster and more efficient than trying to use FTP to do filesystem read/write operations on a network connection.

[tonypartridge]

Also, it’s worth noting if you are using shell to extract the files you should be changing the file ownership on extraction. If that’s not something you know how to do you probably shouldn’t be using ssh to extract files.

[tonypartridge]

And I agree with @PhilETaylor, because I've just checked the J! Source code and that doesn't exist anywhere. We connect then ftp_login.

[joomla-cms-bot]

Set to "closed" on behalf of @Quy by The JTracker Application at issues.joomla.org/joomla-cms/19960

[Quy]

Closing since non-producible as stated above.

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/19960.}