Drop the FTP Layer for Joomla 3.0?

[Mark Dexter]

Hi everyone. I wanted to start a conversation about the possibility of
dropping the FTP Layer in Joomla version 3.0. The FTP layer was added
in version 1.5 to:

"overcome perennial problems that have been experienced by many
Linux/Unix host Users in the past where there are file write
permission issues with the Users Host Provider particularly on Shared
Hosting servers. This can significantly affect the installation of new
Extensions or writing to the configuration.php file.
Using the FTP Layer eliminates the need to make directories and files
writable and thus improves overall security of the installation and
server. It also makes the site administrators job a lot easier!"
(taken from the 1.5 installation manual)

The FTP layer complicates the code in the com_installer and it is a
part of the package that is rarely tested (because no one uses it?).

Is it fair to say that, with most decent hosting companies, the FTP
Layer is not needed? What do people think? Do you use it? Do people
need it?

Thanks. Mark

[Pedro Arroyo]

Por lo menos a mi me ha servido en mas de una oportunidad. 

Creo que se podría prescindir de la capa siempre y cuando se haga algún tipo de documentación (no muy extensa) que permita configurar los permisos de archivo y colgada en la pagina oficial de joomla.

Mucha gente en esta lista de distribucion pensara que esto es una niñeria o una estupidez. pero pienso que si quitas una funcionalidad que entrega una solucion rapida, debes reponer con algun otro camino que te permita llegar al mismo destino.

2012/7/3 Mark Dexter <dexter...@gmail.com>

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To post to this group, send an email to joomla-...@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-cm...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/joomla-dev-cms?hl=en-GB.

--
Saludos cordiales,
Pedro Arroyo M.

[Emerson da Rocha Luiz]

In some rare cases on last years this feature could be useful at least to me. But very rare cases. But when I really needed in the past, in situations in which it was not just send an email to support and wait, this feature did not work. Maybe on 1.6? I do not remember.

In any case, is a good functionality, at least from the standpoint of being supported by JPlatform. For me, the CMS can even remove it, but is a loss do not have it in the framework.

Anyway, if because of this feature, the Joomla 3.0 should be postponed, it would be better to postpone just this feature, and re-implementation of this functionality when ready again than releasing with serious errors.

emerson

--

Emerson Rocha Luiz
+55 51 9881-9146 | Skype: fititnt | GTalk: fititnt | Twitter: @fititnt | http://www.fititnt.org

Membro do JUGRS

[Rouven Weßling]

On 04.07.2012, at 01:01, Emerson da Rocha Luiz wrote:

In any case, is a good functionality, at least from the standpoint of being supported by JPlatform. For me, the CMS can even remove it, but is a loss do not have it in the framework.

The platform has already decided not to expand this feature. For example the new JLog class doesn't really work with FTP.

Rouven

[Niels Braczek]

Am 04.07.2012 00:43, schrieb Mark Dexter:

> Is it fair to say that, with most decent hosting companies, the FTP
> Layer is not needed? What do people think? Do you use it? Do people
> need it?

I have a couple of customers using the FTP layer. I'd prefer not to drop it.

Having a file system abstraction layer does make things more
complicated, as does a database abstraction layer. But the flexibility
it gives is worth it. Imagine adding events to the operations - that
would make versioning of files feasible.

Regards,
Niels

--
| http://barcamp-wk.de · 2. Barcamp Westküste Frühjahr 2013 |
| http://www.bsds.de · BSDS Braczek Software- und DatenSysteme |
| Webdesign · Webhosting · e-Commerce · Joomla! Content Management |
------------------------------------------------------------------

[Troy]

Many hosts still use "DSO" as the default user environment, Liquidweb
and I'm pretty sure Hostgator being 2 of them..
Bear

[Amy Stephen]

Joomla's FTP layer is something that set it apart from other CMS'es. It's introduction in 1.5 cut frustrated forum posts and desperate 777 chmods in a noticable way -- it meets a need, for certain and I am absolutely certain that part of the reason WP added FTP support is because they saw it worked for Joomla users.

Also, I have not explored specifically why, but I wonder if it's related to the something that has to do with the FTP layer, but Joomla also does much better on a Mac than other open source software, too.

Permissions and ownership are a pain. Joomla's FTP layer has been a notable and appreciated success these past years since it was/is very helpful to users.  I cannot think of one other improvement that helped so many so dramatically.

Definitely agree with not storing the credentials for this service, but, in all honesty, removing it will create problems that Joomla users have not faced for years and there will be confusion and frustration if it goes away.

Understand "finding a good host" is important, but the reality is, that just doesn't always happen.

It won't be the end of the world, the motivation for considering this makes sense, but I hope Joomla keeps it.

[Joseph LeBlanc]

FWIW, we ended up using the FTP layer for a client earlier this year. We probably should have told this client "tough, find better hosting," but we were running up against a hard deadline. It was there, so I used it.

It's definitely handy to have when you need it, but I do hear the argument that we're just encouraging people to use inadequate hosting. I'd lean towards keeping it, but would gladly give it up for improvements in com_installer.

Regardless of whether it stays or goes, I would definitely remove the configuration step for it from the initial installation process.

-Joe

[Karlos Rikaryo]

Friends the FTP in Joomla! I have used in my projects since version 1.5 and makes it much easier to be making contact with the hosting server to modify permissions is much waste of time, all my projects this with this function enabled and works perfectly, it would be interesting to always check and improve...

hugs

Karlos Rikaryo

Joomla! Brasil

www.rikaryo.com.br

+55 88 96238664

rik...@gmail.com

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-cms/-/VjMlOtnx8JUJ.

[Marius van Rijnsoever]

Definitely vote to keep the ftp layer. Personally I dont use it (have
my own servers), but I have seen a lot of clients use it.

I have tried in the past to get file permissions fixed for clients (in
order to avoid the ftp layer), even giving the command to the support
tech to fix it (chown www-data:www-data -R /directory), but even then
I had issues as the support staff believed I was trying to hack the
server :P

The only way to setup Joomla on "bad hosts" would be to first install
Joomla, then install joomlaxplorer, then unzip joomla again in a
different directory (in order for the files to be owned by apache
(instead of cpanel or ftp user) and re-install Joomla.

Loosing the FTP option would also mean flooding the forums with
questions, even if you think 99% of users do not use this option, it
would still mean 16.000 sites will stop working
(http://trends.builtwith.com/cms/Joomla!)

Thanks, Marius

[Liam Edwards]

That makes it impossible to use Joomla! 3.0 for people with a bad Web Host... So it would be a good step, but at the same time you disallow people to upgrade or even use Joomla! 3.0, unless they put the FTP Layer Function in there themselves again, and not everyone wants (or can) (to) do that.

Op dinsdag 3 juli 2012 23:43:58 UTC+1 schreef Mark Dexter het volgende:

[Nick Weavers]

I am interested in why it is viewed that only "bad hosting" needs the FTP layer. Can someone explain?

I have private servers and I still set up file permissions under the httpdocs (apache root directory) as follows:

chown -R <my_ftp_username>:psaserv *

(psaserv is a group used by plesk that gives the plesk (c-panel like tool) access along with www-data). Plesk works properly with Linux file permission and understand groups, whereas apache/php only looks at owner.

find . -type d chmod 1755 {} \; # Recurse through directories giving them owner (ie ftp user) rwx, group r-x, and other r-x, and setting the sticky bit

find . -type f chmod 644 {} \; # Recurse through directories giving files owner (ie ftp user)  rwx, group r-x, and other r-x

This has worked well for me for most as it stops anything running as www-data from updating, renaming or deleting files which in my mind improves security.

It also means my windows IDE can upload to the server using the same FTP account. 

Nick

[Mark Dexter]

Well, I think we can safely say that there is a strong preference for
keeping the FTP.

Now, is there anyone that is willing to help test this as we go
forward? That is the biggest challenge with keeping it. If a few
people can help test this, especially with the upcoming alpha and beta
releases, that would really help us to make sure it keeps working for
3.0. Thanks! Mark

On Wed, Jul 4, 2012 at 3:51 AM, Lapoux Sébastien
<sebastie...@seblod.com> wrote:
> Hi,
>
> Like some people said, it will be sad to lose this advantage (see Amy answer
> about Wordpress).
>
> In my experience, we met the permission file issue on almost all Joomla
> websites for which we don't manage the hosting… that's means a lot…
>
> We have not managed the FTP layer on SEBLOD 1.x for Joomla, we added it on
> SEBLOD 2.x for Joomla 2.5 because it's a lot asked by SEBLOD users and
> require for some our clients.
>
> I don't think it's a specific French issue ;), we met this issue recently on
> "Rackspace" hosting. It depends of course of who is in charge of the hosting
> installation… sorry for network administrators, but to find or work with
> very good network administrators is clearly not the global situation…
>
> Best Regards
>
> Sébastien Lapoux

>
> --
> You received this message because you are subscribed to the Google Groups
> "Joomla! CMS Development" group.
> To view this discussion on the web, visit

> https://groups.google.com/d/msg/joomla-dev-cms/-/NXbLxjyCN48J.

[Amy Stephen]

I use it in the platform with Molajo -- and will absolutely continue testing it.

[Nick Weavers]

I would be happy to test it.

I am still intrigued by the claim that it is only needed for bad hosting providers. Can anyone elaborate?

Nick

[Amy Stephen]

It is often considered a better hosting arrangement to have suPHP available to help manage file permissions. Right or wrong, there tends to be an assumption that hosts who do not use suPHP also use other default/inexpensive/less than secure approaches that tend not to follow best industry practices.

Nick

--

You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-cms/-/2efdFyOIrWYJ.

[Rune V. Sjøen]

I would argue towards keeping the FTP layer as-is until the CMS is on a platform that supports the new JFileSystem package and then make an effort to migrate towards using JFileSystem, which could theoretically open up for using other transports as well and make it much more flexible. 

- Rune

On Thursday, 5 July 2012 14:09:51 UTC+2, Amy Stephen wrote:

It is often considered a better hosting arrangement to have suPHP available to help manage file permissions. Right or wrong, there tends to be an assumption that hosts who do not use suPHP also use other default/inexpensive/less than secure approaches that tend not to follow best industry practices.

On Thu, Jul 5, 2012 at 5:50 AM, Nick Weavers <nickw...@yahoo.co.uk> wrote:

I would be happy to test it.

I am still intrigued by the claim that it is only needed for bad hosting providers. Can anyone elaborate?

Nick

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-cms/-/2efdFyOIrWYJ.

To post to this group, send an email to joomla-dev-cms@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-cms+unsubscribe@googlegroups.com.

[Micheas Herman]

On Thursday, July 5, 2012 3:50:00 AM UTC-7, Nick Weavers wrote:

I would be happy to test it.

I am still intrigued by the claim that it is only needed for bad hosting providers. Can anyone elaborate?

FTP is as insecure as telnet and should not be used over untrusted networks like the internet.

If you are actively using the ftp layer over the internet to upload files it is a question of when, not if, your login credentials are lifted and malware uploaded to your site.

It is user friendly but very stupid. (sort of like not requiring ssl for login forms.) 

Nick

[Andreas Tasch]

@Micheas

Agree that FTP should be used with SSL, BUT in 99,9% the FTP-Server is localhost/127.0.0.1 (which is the default option), so it is very likely that a MITM attack is NOT possible.

Imho, the option should stay somewhere (maybe you can remove it from installation), it is handy until the client switches to a better host.

@Nick, as Amy wrote but in more detail:

If PHP is used as module (mod_php) it runs with the privileges of the webserver (e.g.) Apache. The directory/file permissions are usually set to another user (mostly ftp-user). So if a PHP script (e.g. Joomla! media manager picture upload) tries to write a file to the filesystem it does that with the webserver permission - and either this fails (if safe_mode is enabled) or you can not delete/edit the files with FTP data afterwards.

The FTP-layer ensures (I assume this, have not looked into the code) that the file is stored with the correct permissions (of FTP-user). This is somehow a workaround and not good practice.

Therefore "good hosts" ensure that the PHP scripts are executed with the correct user permissions (and not as webserver). This works with e.g. Apache -> suexec, mod_suphp, PHP as CGI, mod_fcgi, mod_fcgid. 

[Russ Winter]

following on from Andreas' explanation,  the previous example of using the "sticky-bit" (note: using the sticky-bit is normally reserved for further restricting or limiting access, not elevating access) to set the group ownership to allow the hosting service user access to a users directory is also, in professional security fields, considered to be an elevation of permissions for a unrelated account to the accepted owner, hence in some rare situations of system compromise, could allow a hijacked web/php process to access all other folders that also have that elevated group access, including any processes running with that group being allowed access. This would include the systems "/tmp" folder in many cases and the PHP "temp/session" directory.  

So it is generally accepted in these circles that phpSUExec (& suExec) are preferred methods, reducing the risk of system process access, whilst still providing a compatible, multi-user, permissions schema. This method always offers good Systems Admins with a traceable usage mechanism if any problems are observed.  100% protection is not feasible, so audit-ability and tracking is paramount, remember ~ it's not a matter of "if", it's a matter of "when" a breach is going to occur. 

--

You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-cms/-/UiXbUhhIkYIJ.

To post to this group, send an email to joomla-...@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-cm...@googlegroups.com.

[Troy]

Well, lets see... 18yrs using the net, and NEVER ONCE been hacked via FTP.  Proper jails and firewalls & passwords prevent 90% of such vulnerabilities

Bear

--

You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-cms/-/bz7rFnDVvisJ.

[Nick Savov]

Hi Micheas, et al.,

Do you know if it would be relatively easy to implement FTPs into the
Joomla core?
http://en.wikipedia.org/wiki/FTPS

Kind regards,
Nick

[piotr_cz]

I agree, that in we should discourage picking dodgy webhosts, but my experience is that all kinds of scenarios may happen:

- client decides to buy domain and chooses webhosting influenced by price/ neighbor/ beer buddies. Then hires web development studio.

- web developer inherits some stuff to refactor, and 'just add that thing CMS so I can edit texts myself'

Changing webhosting bundles in some countries (Poland) may be extremely painful and adds extra costs. It's long time since I've used FTP layer but this may be any time.

[Micheas Herman]

On Thursday, July 5, 2012 9:38:36 PM UTC-7, Bear wrote:

Well, lets see... 18yrs using the net, and NEVER ONCE been hacked via FTP.  Proper jails and firewalls & passwords prevent 90% of such vulnerabilities

Bear

 

You've been lucky. Congratulations. There are sites running Joomla 1.5.0 that have never been hacked. They have also been lucky.

While I haven't had FTP on any of my servers this century. 

My record for a month is cleaning up three defaced Joomla sites that had been compromised via FTP.

Proper passwords do not protect you against sniffing attacks as the password goes over the net in plain text.

Also, how would you know that you have never been hacked via ftp? Do you check the ip addresses used to log in and make sure that none of 

them are legitimate?

http://www.nirsoft.net/utils/password_sniffer.html is an example of the almost zero skill needed to compromise ftp.

 

On 7/5/2012 1:01 PM, Micheas Herman wrote:

On Thursday, July 5, 2012 3:50:00 AM UTC-7, Nick Weavers wrote:

I would be happy to test it.

I am still intrigued by the claim that it is only needed for bad hosting providers. Can anyone elaborate?

FTP is as insecure as telnet and should not be used over untrusted networks like the internet.

If you are actively using the ftp layer over the internet to upload files it is a question of when, not if, your login credentials are lifted and malware uploaded to your site.

It is user friendly but very stupid. (sort of like not requiring ssl for login forms.) 

Nick

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-cms/-/bz7rFnDVvisJ.

To post to this group, send an email to joomla-dev-cms@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-cms+unsubscribe@googlegroups.com.

[Micheas Herman]

On Friday, July 6, 2012 8:33:17 PM UTC-7, Nick Savov wrote:

Hi Micheas, et al.,

Do you know if it would be relatively easy to implement FTPs into the
Joomla core?
http://en.wikipedia.org/wiki/FTPS

It would be pretty simple if it hasn't already been done.

quoting the documentation:

ftps:// was introduced in PHP 4.3.0. It is the same as ftp://, but attempts to negotiate a secure connection with the ftp server. If the server does not support SSL, then the connection falls back to regular unencrypted ftp.

The only issue I can see with this is that someone could get compromised without knowing it if the server is running ftp for anonymous downloads  and the ftps daemon does not respond.

I guess one could test if ftpd is running on the server and warn that  this could result in the ftps password being exposed.

Kind regards,
Nick

>
> On Thursday, July 5, 2012 3:50:00 AM UTC-7, Nick Weavers wrote:
>>
>> I would be happy to test it.
>>
>> I am still intrigued by the claim that it is only needed for bad hosting
>> providers. Can anyone elaborate?
>>
>
> FTP is as insecure as telnet and should not be used over untrusted
> networks
> like the internet.
>
> If you are actively using the ftp layer over the internet to upload files
> it is a question of when, not if, your login credentials are lifted and
> malware uploaded to your site.
>
> It is user friendly but very stupid. (sort of like not requiring ssl for
> login forms.)
>
>>
>> Nick
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Joomla! CMS Development" group.
> To view this discussion on the web, visit
> https://groups.google.com/d/msg/joomla-dev-cms/-/bz7rFnDVvisJ.

> To post to this group, send an email to joomla-dev-cms@googlegroups.com.

> To unsubscribe from this group, send email to

> joomla-dev-cms+unsubscribe@googlegroups.com.

[Sam Moffatt]

PHP's FTP implementation is impossible to use. I tried at one point to
switch over to it however the performance penalty it applies in
comparison with the JFTP client library was horrific for some of the
larger Joomla! extensions in the installer. The primary problem is
that PHP's FTP implementation will open a connection for each file you
transfer which means for every file you write there is an open, write
and close. That starts to add up in terms of time when you add more
and more files (a standard Joomla! extension easily has 20 files
without trying to hard; that's 19 opens and closes more than the
core).

Cheers,

Sam Moffatt
http://pasamio.id.au

>> > To post to this group, send an email to joomla-...@googlegroups.com.

>> > To unsubscribe from this group, send email to

>> > joomla-dev-cm...@googlegroups.com.

>> > For more options, visit this group at
>> > http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
>> >
>> >
>

> --
> You received this message because you are subscribed to the Google Groups
> "Joomla! CMS Development" group.
> To view this discussion on the web, visit

> https://groups.google.com/d/msg/joomla-dev-cms/-/4-7hyQgvQk8J.
>
> To post to this group, send an email to joomla-...@googlegroups.com.

> To unsubscribe from this group, send email to

> joomla-dev-cm...@googlegroups.com.

[Rouven Weßling]

JFTP is using the native PHP implementation if it is available.

Best regards
Rouven

[Sam Moffatt]

ftps:// is the PHP stream wrappers which is what I was referring to as
being slow (to be clear). JClientFTP uses PHP's FTP functions
(http://us3.php.net/manual/en/ref.ftp.php) to connect which doesn't
use stream wrappers and doesn't feature this automatic open/close
behaviour.

Cheers,

Sam Moffatt
http://pasamio.id.au

[Nick Savov]

We could at least eliminate it from the installer if there's a consensus.  Right now that step comes even before the Admin login information and site details.

Kind regards,

Nick

[Matt Thomas]

Is there a need for it to be in the installer, other than writing the ftp information to configuration.php? Will any part of the initial installation break if it's not enabled right away? If not, I'm in favor of removing it from the there.

I personally don't use it, and can't remember if I ever have, but would be happy to help test it.

Best,

Matt

Sent from my phone that uses an open source operating system.

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-cms/-/N-58K3-OIToJ.

[brian teeman]

What is the problem you are looking to solve by removing it from the installer

On Sunday, 15 July 2012 13:13:46 UTC+1, betweenbrain wrote:

Is there a need for it to be in the installer, other than writing the ftp information to configuration.php? Will any part of the initial installation break if it's not enabled right away? If not, I'm in favor of removing it from the there.

I personally don't use it, and can't remember if I ever have, but would be happy to help test it.

Best,

Matt

Sent from my phone that uses an open source operating system.

On Jul 14, 2012 11:54 PM, "Nick Savov" <ni...@iowawebcompany.com> wrote:

We could at least eliminate it from the installer if there's a consensus.  Right now that step comes even before the Admin login information and site details.

Kind regards,

Nick

On Wednesday, July 4, 2012 5:11:31 PM UTC-5, Mark Dexter wrote:

Well, I think we can safely say that there is a strong preference for
keeping the FTP.

Now, is there anyone that is willing to help test this as we go
forward? That is the biggest challenge with keeping it. If a few
people can help test this, especially with the upcoming alpha and beta
releases, that would really help us to make sure it keeps working for
3.0. Thanks! Mark

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-cms/-/N-58K3-OIToJ.

To post to this group, send an email to joomla-dev-cms@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-cms+unsubscribe@googlegroups.com.

[Niels Braczek]

Am 15.07.2012 14:13, schrieb Matt Thomas:

> Is there a need for it to be in the installer, other than writing the ftp
> information to configuration.php?

Writing the configuration file.

Regards,
Niels

--
| http://barcamp-wk.de · 2. Barcamp Westküste Frühjahr 2013 |
| http://www.bsds.de · BSDS Braczek Software- und DatenSysteme |
| Webdesign · Webhosting · e-Commerce · Joomla! Content Management |
------------------------------------------------------------------

[Matt Thomas]

On Sun, Jul 15, 2012 at 8:25 AM, Niels Braczek <nbra...@bsds.de> wrote:

Am 15.07.2012 14:13, schrieb Matt Thomas:

> Is there a need for it to be in the installer, other than writing the ftp
> information to configuration.php?

Writing the configuration file.

That seems like a very compelling reason to keep it in the installer for users that need it then.

Best,

Matt Thomas

Founder betweenbrain™

Lead Developer Construct Template Development Framework

Phone: 203.632.9322
Twitter: @betweenbrain

Github: https://github.com/betweenbrain 

[Rouven Weßling]

On 15.07.2012, at 15:40, Matt Thomas wrote:

> That seems like a very compelling reason to keep it in the installer for users that need it then.

The installation will work fine without the FTP mode. As the last step you'll have to manually upload the configuration.php and of course you have to remove the installation folder manually.

I'd guess the main motivation of removing it from the installation, besides code simplification, is saving one installer step and also discouraging the use of the FTP mode.

Best regards
Rouven

[Amy Stephen]

Agree. Those sites that need it are notified during the configuration.php save.

Might be worthwhile to remove the FTP step during install and also from the Global Configuration. Then, when people are prompted to manually save the configuration.php file, they could be linked to a wiki page that explains how to manually turn on the feature, when they would need it, warn them not to permanently leave credentials in the configuration file, etc.

That will reduce the accidental configurations that are certainly happening today and still leave the feature for now for those who need it. Probably reasonable that it be restricted to those who can jump through a few more hoops to use it. The live_site is another setting that is manually offered, so it could be treated like that.
 

Best regards
Rouven

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

[Terrance W. Arthur]

I may be confused but it seems that it is being proposed that to save an installer step I will now have to manually save the config file? Is that what I am reading here?

Accidental configurations? Can you elaborate on what you mean by that please?

How about not fixing things that aren't broken and leave it as it is. There are plenty of actual issues that need to be dealt with like all the bugs that need patches.

There are plenty of servers out there that need this feature and it isn't really fair to remove it and make them jump through extra hoops for no reasons other than to save an installer step that clearly states you can most likely skip it.

I don't agree with trying to force folks to do things your way especially when the FTP layer was added to reduce support needs and manually saving the config file will only add to support issues.

Terry Arthur

Sent from my iPad

[elin]

I really think the install process is a different question, and I know Kyle already has been doing a lot of work to eliminate unnecessary clicks there.

  

One of the interesting twists of the ftp layer is that if you do need it and you don't store it you will have to give ftp access to all of your users who you allow to upload images. And then indeed they will have to pass that over the the tubes from their malware infected computers every time they want to upload an image.  So I actually think that saying "don't ever store" (and I have said this myself) is very much a two edged sword. As usual we might want to ask who it is that has the ability to read your configuration.php file and why you are giving them this access. At the point that bad-intending people have access to your  filesystem you are already in pretty bad trouble ftp layer or not.    Also note that if you do not store your ftp credentials there is a catch 22 in updating your global configuration because you can't write the changes. 

Unfortunately, users in general don't know that they need the ftp layer to successfully install until after they have unsuccessfully installed so the process right now really makes no sense for first time installers. Wouldn't it make more sense to let them set up FTP at the point when they know they need it i.e. when writing has failed?   It would be really great to perhaps look at the UI when writing configuration.php fails and make it so that at that point only those users who need it get the option in the UI to create the file "manually."   I always wonder how much abandonment we get at that point.

Elin

On Sunday, July 15, 2012 11:17:49 AM UTC-4, terryarthur wrote:

I may be confused but it seems that it is being proposed that to save an installer step I will now have to manually save the config file? Is that what I am reading here?

Accidental configurations? Can you elaborate on what you mean by that please?

How about not fixing things that aren't broken and leave it as it is. There are plenty of actual issues that need to be dealt with like all the bugs that need patches.

There are plenty of servers out there that need this feature and it isn't really fair to remove it and make them jump through extra hoops for no reasons other than to save an installer step that clearly states you can most likely skip it.

I don't agree with trying to force folks to do things your way especially when the FTP layer was added to reduce support needs and manually saving the config file will only add to support issues.

Terry Arthur

Sent from my iPad

On Jul 15, 2012, at 11:02 AM, Amy Stephen <amyst...@gmail.com> wrote:

On Sun, Jul 15, 2012 at 9:47 AM, Rouven Weßling <m...@rouvenwessling.de> wrote:

On 15.07.2012, at 15:40, Matt Thomas wrote:

> That seems like a very compelling reason to keep it in the installer for users that need it then.

The installation will work fine without the FTP mode. As the last step you'll have to manually upload the configuration.php and of course you have to remove the installation folder manually.

I'd guess the main motivation of removing it from the installation, besides code simplification, is saving one installer step and also discouraging the use of the FTP mode.

Agree. Those sites that need it are notified during the configuration.php save.

Might be worthwhile to remove the FTP step during install and also from the Global Configuration. Then, when people are prompted to manually save the configuration.php file, they could be linked to a wiki page that explains how to manually turn on the feature, when they would need it, warn them not to permanently leave credentials in the configuration file, etc.

That will reduce the accidental configurations that are certainly happening today and still leave the feature for now for those who need it. Probably reasonable that it be restricted to those who can jump through a few more hoops to use it. The live_site is another setting that is manually offered, so it could be treated like that.
 

Best regards
Rouven

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

To post to this group, send an email to joomla-dev-cms@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-cms+unsubscribe@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/joomla-dev-cms?hl=en-GB.

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

To post to this group, send an email to joomla-dev-cms@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-cms+unsubscribe@googlegroups.com.

[Troy]

I think elin is on the right track. I don't care for Amy's idea @ all...
imo the best way to handle this would be ..
start the install normally , when you get to the point where your ready
to write files, if it fails then bring up the ftp screen and ask them
for the info, if not, then carry on.
I know its possible to check for read/write ability before even doing
anything so this could easily be handled behind the scenes and users who
don't need the ftp access won't have to worry about it

Seems like a win-win to me. Yes its a bit more work on the coder's
part, but building USER friendly interfaces ALWAYS are.
Bear

[Andreas Tasch]

@Bear, agree, very good idea.

It is not very user friendly to remove a comfortable feature and throw in some hurdles by letting them jump to wiki pages. The feature is there and fixes a hurdle for many beginners, so why discourage them from using joomla. They will find out sooner or later that they are on a crappy host. So the idea of Bear imho is very good.

[Nick Weavers]

I use SFTP or SSH for upload from PC to the web server, but I was happy with the on site FTP method of updating/creating/deleting files since it was localhost to localhost and didn't seem like a big risk (no man in the middle). I've never had a site hacked (that I'm aware of) so far, but I would not like to tempt fate so I've got no problem switching to suphp.

 

[Sam Moffatt]

I'm not sure we're all talking across the same thing. It feels like
the thing that will be updated is the installation application to
shuffle the FTP step from where it is to at the end when it fails to
write the configuration file to add it as an option (as well as being
able to manually copy the file or refresh if someone has fixed the
permissions).

The Installer Component (com_install) uses the JFile/JFolder system
which already abstracts the FTP layer by design. It wouldn't need any
modification should FTP functionality be removed, only the underlying
libraries would need the change.

The risk of the FTP layer is that the password is stored in a web
accessible location by design (encrypting it doesn't necessarily solve
the problem because you still need to make the key available to the
web application that is already reading from your file system). That
means that anyone can read it and then if the FTP is open to the web
(which often in these sorts of shared hosts is also the case) it
permits anyone to read or write the file system which becomes an
attack vector. If you have a CPanel instance and you use the same
credentials for CPanel (which if you're on a cheap shared host that
won't let you create alternate FTP accounts may be reality) then the
attacker also now has access to all of your CPanel and can potentially
view information there and also manage information there.

Cheers,

Sam Moffatt
http://pasamio.id.au

On Mon, Jul 16, 2012 at 5:20 AM, Marco Biagioni <marco...@gmail.com> wrote:
>> We should understand the percentage of use of this feature before remove
>> it.
>
> I 've never used it, but maybe in some cases may be useful.
> I think a solution could be decouple com_installer from this feature
> (everyway a good
> practice) and mantain it in a separate and reusable module

>
> --
> You received this message because you are subscribed to the Google Groups
> "Joomla! CMS Development" group.

> To view this discussion on the web, visit

> https://groups.google.com/d/msg/joomla-dev-cms/-/aQV1lyz2rkAJ.
>
> To post to this group, send an email to joomla-...@googlegroups.com.

> To unsubscribe from this group, send email to

> joomla-dev-cm...@googlegroups.com.

[Amy Stephen]

On Mon, Jul 16, 2012 at 4:44 PM, Sam Moffatt <pas...@gmail.com> wrote:

The Installer Component (com_install) uses the JFile/JFolder system
which already abstracts the FTP layer by design. It wouldn't need any
modification should FTP functionality be removed, only the underlying
libraries would need the change.

And, the FTP step would also need to be removed from com_install, along with the Global Configuration settings, and configuration.php file entry right?

It's clear FTP access is not secure.

What's not clear (to me) is:

A) Will FTP access be removed from the platform? (In other words, has that decision been made? And if so, when will it be removed?)

B) And, if that happens, will FTP access even be an option for com_install?

Thanks.

[Rouven Weßling]

On 16.07.2012, at 23:54, Amy Stephen wrote:

A) Will FTP access be removed from the platform? (In other words, has that decision been made? And if so, when will it be removed?)

There's been no discussion of removing yet, but I don't see it surviving very long if the CMS decides to drop it.

The only thing that has been decided is that the platform won't extend the FTP support to any new classes. This has already bitten logging which doesn't work over FTP. (But this kinda makes sense, imagine opening an FTP connection on every request to put down 2-3 lines of information). 

Rouven

[Amy Stephen]

Yea, logging via FTP would be a little crazy.

Thanks, clears it up for me.

--

You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

[Sam Moffatt]

On Mon, Jul 16, 2012 at 2:54 PM, Amy Stephen <amyst...@gmail.com> wrote:
>
>
> On Mon, Jul 16, 2012 at 4:44 PM, Sam Moffatt <pas...@gmail.com> wrote:
>>
>>
>> The Installer Component (com_install) uses the JFile/JFolder system
>> which already abstracts the FTP layer by design. It wouldn't need any
>> modification should FTP functionality be removed, only the underlying
>> libraries would need the change.
>
>
> And, the FTP step would also need to be removed from com_install, along with
> the Global Configuration settings, and configuration.php file entry right?

I'm confused, which FTP step in com_install? I assume that you mean
com_installer the Extension Manager not the web application installer
of the app which installs the core app but really this is all
confusing because I can't work out if people mean the extension
installer or the base CMS installer. The only FTP thing in
com_installer is a username/password prompt. And that is only done if
the FTP mode is enabled and there are no credentials available.
Realistically FTP mode could be nuked almost everywhere without the
com_installer being impacted remotely, it'd only be a dead code path.
There certainly isn't a "step" in there beyond a simple prompt that
appears if FTP is configured without a username or password which
neatly reconfigures itself if it isn't necessary to be hidden (and
thus ignored if not available).

Can you be clear which FTP "step" you mean?

Sam Moffatt
http://pasamio.id.au

[Amy Stephen]

On Tue, Jul 17, 2012 at 1:58 AM, Sam Moffatt <pas...@gmail.com> wrote:

Realistically FTP mode could be nuked almost everywhere without the
com_installer being impacted remotely, it'd only be a dead code path.
There certainly isn't a "step" in there beyond a simple prompt that
appears if FTP is configured without a username or password which
neatly reconfigures itself if it isn't necessary to be hidden (and
thus ignored if not available).

Can you be clear which FTP "step" you mean?

What you just described in the quoted section. =)

[Sam Moffatt]

So you aren't talking about the FTP step in the CMS base installer
with the big red text saying this is probably not for you?

Cheers,

Sam Moffatt
http://pasamio.id.au

> --
> You received this message because you are subscribed to the Google Groups
> "Joomla! CMS Development" group.

[Peter van Westen]

I am currently overhauling the J3.0 installer.

It will simply only show the FTP config page if the configuration.php or root folder is not writable.

The FTP settings will still be fully available in the global configuration.

From the different reactions in this thread I don't think it is smart to remove the FTP settings completely yet. Maybe in Joomla 4.0? :)

[Troy]

+1

Bear

--

You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-cms/-/8XQc2tFGoqIJ.

[Nick Savov]

Nice one, Peter! Post the tracker # id when you have it, please.

Kind regards,
Nick

> I am currently overhauling the J3.0 installer.
> It will simply only show the FTP config page if the configuration.php or
> root folder is not writable.
>
> The FTP settings will still be fully available in the global
> configuration.
>
> From the different reactions in this thread I don't think it is smart to
> remove the FTP settings completely yet. Maybe in Joomla 4.0? :)
>

> On Wednesday, 4 July 2012 00:43:58 UTC+2, Mark Dexter wrote:
>>
>> Hi everyone. I wanted to start a conversation about the possibility of
>> dropping the FTP Layer in Joomla version 3.0. The FTP layer was added
>> in version 1.5 to:
>>
>> "overcome perennial problems that have been experienced by many
>> Linux/Unix host Users in the past where there are file write
>> permission issues with the Users Host Provider particularly on Shared
>> Hosting servers. This can significantly affect the installation of new
>> Extensions or writing to the configuration.php file.
>> Using the FTP Layer eliminates the need to make directories and files
>> writable and thus improves overall security of the installation and
>> server. It also makes the site administrators job a lot easier!"
>> (taken from the 1.5 installation manual)
>>
>> The FTP layer complicates the code in the com_installer and it is a
>> part of the package that is rarely tested (because no one uses it?).
>>
>> Is it fair to say that, with most decent hosting companies, the FTP
>> Layer is not needed? What do people think? Do you use it? Do people
>> need it?
>>
>> Thanks. Mark

>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Joomla! CMS Development" group.
> To view this discussion on the web, visit

> https://groups.google.com/d/msg/joomla-dev-cms/-/oHydtIl4bS8J.

[Amy Stephen]

Excellent Peter! Agree, there is little support to remove it at this time, your approach will be a good step forward.