This is a pretty neat idea, but what is wrong with FTP?

This may be a perl site, but I can see only one case where you wouldn't want to use FTP to transfer files: port 21 is unavailable to you.

What advantages does this have over using already established and reasonably secure standards for transferring files?

This also seems a lot like security by obscurity. You are using a port only YOU know, right? Well anyone with a port scanner and a grudge can find out anything. Trust me.

I am not being cruel, but I'm just adding a SysAdmin's point of view. I don't like rolling my own solution when standard solutions work so well.

Subscribe to lwall's virtue of laziness. It will save you time and energy.

J. J. Horner
Linux, Perl, Apache, Stronghold, Unix
jhorner@knoxlug.org http://www.knoxlug.org/

You mentionned it: port 21 is not available to me everywhere. At work, I have only two or three ports open.

Also, FTP is *not* as secure, since it requires sending your password over the network.
As for the port scanner dealy, well, you did not read well what I wrote: you leave your litte file server running 10 seconds - the time to upload the file(s) - and then you shut it down.

It is very unlikely that somebody will connect to your machine and mess around with it during that time!

The point of your original post seemed to be that this would make it somehow easier to update a site. Does it? Let's go through the steps for each.

Your way (if I understand you correctly)

• Start up mini-ftp server
• Open big-honking browser that can handle multipart encoding
• Go to URL with file input field
• click browse, navigate, and select ortype the filename
• click go (or have it upload onChange or something equally silly)
• Shut down mini-ftp server

Using ftp from command line

• change to directory where file resides
• ftp to your server
• Enter username, password
• put file
• quit

Frankly I don't see a great deal of time saved or a huge improvement in useability. Although it is clever, it seems like it might just be easier and quicker to ftp (or sftp, or scp). And although the risk is slight from a security stand point, it does make me curious whether you've ever forgot to turn out the lights.

I use FTP to transfer files to/from work that I don't want to add to CVS. Sometimes I am on my home computer connecting to the ftp server at work, sometimes I have already telneted to work, and so it is simpler to just ftp to my home computer. Well, my ISP has had abusers sharing accounts with all their friends, so they started blocking all the ports < 1024. So, I just run ftp on port 10021. It's rather painless to type ftp aighearach.homeip.net 10021 instead of just ftp aigherach.homeip.net. (oh yeah, telnet is port 5050, login guest... ;)

Paris Sinclair    |    4a75737420416e6f74686572
pariss@efn.org    |    205065726c204861636b6572
I wear my Geek Code on my finger.

as jjhorner said, gaggio's method is an example of "Security by Obscurity", which works to the extent that no one finds anything while poking around in the dark with a flashlight (and believe me, there is a flashlight for every manner of obscurity). solutions correctly employing strong cryptography are the way to go if you want security more worthy of your faith.

I would be tempted to write something like this from this approach:
1) have the bulk of this program be on the in-house "devel" web server
2) write it as a wrapper for scp (which can be made to work through firewalls pretty easily)

This would keep the security of scp without adding the possiblity of creating new security holes
At this point you could write the app to be as grandiose as you wanted, integrity checks for the file, bulk uploads of major sections, etc...

/\/\averick

(be kind this is my first post to perl monks...)

Can you write an FTP script in 10 lines? No, no, it is much simpler than FTP.

And security is just "extra". The main reason to use this system is to have one single form to update both files and text, without using POST file upload through the form.

I like the rhyme, though, but I prefer clarity than obscurity, redmist.

Well, using Net::FTP I would think that it would _very_ easy to write an FTP script in ten lines or even less.

--
<http://www.dave.org.uk>

European Perl Conference - Sept 22/24 2000
<http://www.yapc.org/Europe/>

This is cool, but even cooler would be to download the file in a similar manner. There is a userland solutin to do this but even cooler would be like this:

• Have an "Edit this page" link on each page
• When pressed, contacts the server on your machine and downloads file
• Starts HTML editor of your choice (that has been setup in a preferences file) with file
• Finally uploads the file back

/jeorgen

I used to work for a company that had many web developers. The production environment was set up with one "master" server on the inside of the firewall. All the web developers would access it using SMB/SAMBA, mounting it as a drive to their PC. They could move files around with tools no more complicated than Windows Explorer. There was a scheduled job (also could be triggered on-demand) that would use SCP to push the files from the "master" out to the "live webservers" that served the content to the world. This also had the added benefit that if any of the live webservers were ever hacked they could be rebuilt easily by just refreshing them from the master.

This is not a good solution for every environment (particularly not good for small environments), but for some situations it works very well.