Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support handling retries on Authentication Exceptions #1512

Open
joaocc opened this issue Mar 20, 2024 · 1 comment
Open

Support handling retries on Authentication Exceptions #1512

joaocc opened this issue Mar 20, 2024 · 1 comment

Comments

@joaocc
Copy link

joaocc commented Mar 20, 2024

This feature is to support some scenarios where a ftp client contacting a ftp server in passive mode is running inside a VPC/VNet whose exit to the internet doesn't have a single fixed exit IP.
In these cases, new connections established by PASV commands will fail authentication if they happen to exit the cloud provider through a different IP than that of the main connection.

While normally an authentication failure is not retry-worthy (as it's unlikely the conditions causing the failure change between retries), in this case it would help. In a N availability zone config, commands have broadly speaking a 1/N prob of exiting through the same IP that the main connection did.

Allowing the existing retry mechanism to also (optionally) apply to this phase of the connection would help make code less cumbersome (vs having to retry explicitly at the application level).

Thanks

@FanDjango
Copy link
Collaborator

My first thought, was to think about the initial connection to the server (and forgot about data connections later on in the session).

Current connection logic does not retry, it just fails. There is the "AutoDetect" logic, and yes, this does react to Auth failures in that it aborts further attempts to connect in different modes when ecnountering an Auth failure. So far so clear - you are saying that a Connect-Retry loop would be optionally a good thing.

make code less cumbersome (vs having to retry explicitly at the application level)

Yes, this is what I myself needed to code in one of my own applications.

Note that above, I have mixed "Connect" (initial connect to server) and "connect" (all connections, especially data connections). I understand the difference and see that the low level "connect" could be enhanced to optionally loop a number of retries, without any huge coding effort - simply to "hope for a suitable IP" - by the way, regardless of failure reason, even.

if they happen to exit the cloud provider through a different IP than that of the main connection

It is a bit of an edge case, but should be easy to do.

Any possibility you might want to look at the code (in FtpSocketStream.cs Connect(...)) yourself and make the changes?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants