Transfer Queue not using password

When using the Transfer Queue to download files, the log for that specific transfer will report the following error:

[17:15:09] 530 Login or Password incorrect.

Steps to reproduce:
  1. First, create a new, blank favorite
  2. Assign this favorite a domain to connect to and a username, but NO PASSWORD
  3. Close the favorites editor
  4. Go to the "Favorites" menu in the main SmartFTP window and select your favorite, it should then make a dialog appear which will ask you for your password (the username field should already be filled in)
  5. Enter your password and click OK
  6. Once connected, drag and drop a file that you want to download to your "Temporary Queue" window
  7. Once the item is in the "Temporary Queue" window, right click it and go to Local >> Select Folder...
  8. Pick a folder to save the file, click OK
  9. Switch over to the "Transfer Queue" window, right click on your file entry, and click "Show Log"
  10. Notice how it will try to connect to the server to download the file, while reporting the error mentioned at the top of this bug report (Invalid login or password)
I believe the reason for this is because the password for the account was never entered in the favorite (for security reasons, of course). I think there's 2 ways to approach this:
  • You could internally and TEMPORARILY save the password for the soul purpose of allowing the transfer queue to silently login JUST to obtain the file.
  • An additional prompt could appear while the transfer queue is logging in to obtain the file which will request a password
In any case, both of the above alternatives could be a toggle feature. "Enable/Disable Silent Transfer Login"? Something of that sort...

Please confirm if this is a bug or just my own problem. Thanks.

Problem confirmed but I do not have a solution.
Saving the passwords temporary is no option. Showing a login dialog in the transfer queue neither.

You may want to consider to encrypt the Favorites.dat with the built-in Windows File Encryption instead of entering the passwords everytime you connect.

If you have any better suggestion please let me know.

Regards,
SmartFTP


Problem confirmed but I do not have a solution.
Saving the passwords temporary is no option. Showing a login dialog in the transfer queue neither.

You may want to consider to encrypt the Favorites.dat with the built-in Windows File Encryption instead of entering the passwords everytime you connect.

If you have any better suggestion please let me know.

Regards,
SmartFTP

If you wouldn't mind giving me some source code I could have a look and possibly implement a solution that you can review. I'm a C++ programmer, not sure what language you're using.

Let me know.

Without source, all I can say is there is *always* a solution. Both of my options are in every way possible. Depending on how you've structured your code, they may be easy or hard to implement. In either case, the solutions are more than possible.

Storing the passwords is not an option for me. Even if the passwords are encrypted, they're still *saved*.

Get the latest version:
https://www.smartftp.com/download

Two new features:
1. "Don't save password on exit" option in Favorite Item -> General dialog.
2. Login Dialog with "Update Favorite Item" option.

With these new additions you can do the following:
1. Add new Favorite
2. Set the "Don't save password on exit" option to true in the "General" settings dialog of the favorite item.
3. Do not enter a password into the Favorite Item setting.
4. Connect to FTP server.
5. The Login Dialog will show. Enter the Password. Check the "Update Favorite Item" option.

In case you have items queued in the Transfer Queue using the favorite from above you can start it now.

This is the best we can and will do for the moment.

Regards,
SmartFTP

I've actually just thought of a few things I would like to bring to your attention...

I've never seen the transfer queue actually download more than one file at a time. Assuming that it never does, why are you even logging into the control connection when downloading files through the transfer queue?

Let's assume my server can only support 1 connection per IP. If the transfer queue is trying to login to the server when I'm already logged in under the remote browser (through the main window), that's 2 IP's open. The transfer queue should not be able to connect. I have not tested this, but this appears to be the case.

In all honesty, the transfer queue should use the control connection already active and simply send a PASV or PORT command instead of logging in again. Now if your goal is to actually allow transfers to take place when you're not connected to the server, then you can simply do a condition. First check if there is 1 or more active connections to the specified domain. If false, the transfer queue should attempt to create its own control connection to the server (actually logging in) and then creating a data connection. If true, the transfer queue should use an existing control connection and *not* create its own.

Of course, I may be completely misunderstanding things. I'm sure you have a reason for why things are the way they are now. I'm hoping you can explain anything I'm missing.

However, if I am correct about my assumptions, then this is a very serious problem. It will take major changes and require a lot of time to fix. I hope you would be up to the challenge, as this problem affects a huge usability factor in the program.

The following list is ideal and would actually determine whether I use SmartFTP or move onto something else like WS_FTP:
  • How many security options do I have available?
  • Does the program only request my login password once per session?
  • Can the program allow me to NOT save the password in my saved domain (Temporary passwords should *never* be an option with a good code base)?
  • Is the transfer queue properly coded where it takes advantage of all available resources (ie, does it not make an additional connection)?
I'll await your response.