in reply to Compress and FTP files

Very nice. Some two-penny suggestions:
  1. I would suggest to use constant for variables such like $version etc. If it is something should not be modified, specify 'use constant', so its value will not be accidentally changed.
  2. You used quite a lot of 'global' variables. For example, sub ftp_file uses $ftp_file, $ftp_user, $ftp_pass etc, but none of them are passed in as parameters. Try to use variables with a smaller scope.
  3. Things like $ftp_pass should not be stored with the source code, it is a little bit too dangerous. Promopt for password, even can be a GUI interface. (I know, to hard code the password, you could save yourself a little bit time, each time you use this script, but it is not worth compare to the security issue.)
  4. Package it as a class, so other people may reuse your code easily.

Replies are listed 'Best First'.
Re: Re: Compress and FTP files
by gnu@perl (Pilgrim) on Dec 04, 2002 at 16:48 UTC
    Thanks, I agree with you on the scoping issue. That is the next thing I am working on. I do like the idea of setting constants for certain thing like $version.

    I also strongly dislike coding in the login and password for an ftp account, but this program is designed to ftp to one account by default. The user can pass in an alternate ftp server and login / password with the command line options. The one problem I had (and the reason I coded in the login / pasword) is that users who are not allowed access to the ftp server can still use this to place files there. Do you have an idea on a workaround for that circumstance?

    I did consider making it a package, but didn't think it was important enough. I assumed there was already something like this on cpan, I didn't check to see if there was, I just assumed.

      As an alternative to a username/password, you could create a keypair and use something like scp instead of FTP, and only grant access to the private key file to users who are supposed to put files using this program. No password, and you're moving your access control/security problem out to the file system, rather than creating a new security problem. And if you need to replace the key because it has been compromised, you can do it without changing the code.
      --
      Spring: Forces, Coiled Again!
        Great Idea. I had not thought of that method. it would be much easier on the users as well. I will look into it.

        Thanks.