Overriding Connect() / PerformAutoLogin()

Question

Hi,

I have an unusual situation where I have to use a "proxy" ftp server for want of a better word.
This is what I have to do:
1. ftp to "proxy" server with userid and password
2. send user@realserver
3. send realserver password.

Nothing can happen between steps 1. and 2., and the only valid input is that in steps 2. and 3.

There are two problems I am encountering.
1. existing SecureFtpConnection.Connect() (I am using SecureFtpConnection for both this type of connection and for an actual secure connection - in this scenario, it is a regular ftp protocol connection) will call PerformAutoLogin, which I cannot override to do my "double" login.
2. It will also then attempt to change the directory. This is a problem because it will happen after step 1, and thus cause an error.

I was using the free version originally and overrode Connect() to do everything the base Connect() does except that it calls my own version of PerformAutoLogin to do the double login - so by the time it gets to the change directory, that can proceed happily.

Switching to SecureFtpConnection, the Connect() method is far more complex, and really I don't like the idea of duplicating the base functionality in my thin wrapper class, and of course having to maintain that should any update to ftpnetPro change the way it works.

Ideally, Perform AutoLogin would be a virtual method so I could override it in my class and leave Connect() well enough alone
and/or the "automatically change directory" bit would be made optional/removed and my thin wrapper would call base Connect(), with the proxy details and then send the actual user and password details and indeed do a directory change.

Is it possible that these tweaks could be implemented, or can you think of another way around this?

Basically I want to be able to use the proxy or not simply by setting a couple of properties on my wrapper, not fudge it as I am doing or eg by setting the remote dir to null, then connect, then re-set to the actual dir etc....

thanks in advance for your thoughts.

Answer 1

We will make PerformAutoLogin() virtual in the next release.

Also, if you set the AutoLogin property to false, PerformAutoLogin() won't get called and this shouldn't be a problem.

Answer 2

We will make PerformAutoLogin() virtual in the next release.

Also, if you set the AutoLogin property to false, PerformAutoLogin() won't get called and this shouldn't be a problem.

Great thanks re: autologin. Do you have any idea of an ETA on it?
While you're at it, could you consider exposing an IsLoggedIn property too in the same way you expose IsConnected please?
Both PerformAutoLogin and Login would set this value.

I know I could set AutoLogin to false, but others will be using my wrapper and I want it to be as transparent as possible - logically, the double login is all part of the login process, so they shouldn't need to think that they have to use the control in a different way simply because of the proxying
(I know it's dangerous not wanting my programmers to have to think!)

many thanks

Tony

Answer 3

We don't yet have an ETA on the next release as we've just released 4.1.1. We try to make fairly regular releases so it should be within the next month or so. We've already made PerformAutoLogin() virtual in the current code base so this change will definitely be in there.

Answer 4

Thanks for your help Bruce - both here and in private chat.
Very responsive support I must say!