Closed daiplusplus closed 4 years ago
Update:
I found out that the Azure App Service had FTP disabled. I haven't re-run AutoConnectAsync
since changing the setting (because I changed my code to connect using a manual configuration).
When FTP was disabled on the website, Filezilla showed that Azure accepted the username and password and then closed the TCP connection immediately after supplying the password - I didn't think Azure's FTP service would do this: I was expecting it to print an error message (like "FTP is disabled on this website") and then close the connection.
Ok about Azure. But the logs you showed? That is most definitely a bug!
Could you try AutoConnect (non async) and see if that works better? The way its coded it will try each connection setting once (from most desirable to least desirable) and it will stop the moment it finds a working connection setting. I'll debug AutoConnectAsync.
Btw after you fixed Azure, how many tries did it take to auto connect? Can you show logs?
Also, I checked AutoConnectAsync and it looks good. I have no idea how FluentFTP made so many parallel connections and then all got parallely disconnected. Are you calling AutoConnectAsync in a loop or something?
@robinrodricks no, it's a single call to AutoConnectAsync
.
May I have your e-mail or an IM service username so I can send you my code and a screen-recording?
That's fine. Don't need so much info. I still don't know why so many parallel connections are being created.
On Thu, Sep 12, 2019, 9:34 PM Dai notifications@github.com wrote:
@robinrodricks https://github.com/robinrodricks no, it's a single call to AutoConnectAsync.
May I have your e-mail or an IM service username so I can send you my code and a screen-recording?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/robinrodricks/FluentFTP/issues/451?email_source=notifications&email_token=ABT3UKUCZZGKASMCZRYEJ5DQJJSCDA5CNFSM4IV64BMKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6SM4PY#issuecomment-530894399, or mute the thread https://github.com/notifications/unsubscribe-auth/ABT3UKWKSUCGAKQQ4H4CXBTQJJSCDANCNFSM4IV64BMA .
FWIW, it still takes about 18 seconds for AutoConnectAsync
to complete with FTP enabled on the Azure website.
Can you try AutoDetect and see which setting it comes up with? See the FAQ on how to use it..
Also is there a way to detect azure quickly so we could just snap to the correct setting for azure... Currently azure detects as Microsoft FTP or something...
On Thu, Sep 12, 2019, 10:23 PM Dai notifications@github.com wrote:
FWIW, it still takes about 18 seconds for AutoConnectAsync to complete with FTP enabled on the Azure website.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/robinrodricks/FluentFTP/issues/451?email_source=notifications&email_token=ABT3UKXOJIH5T3E4ROYKETTQJJXYBA5CNFSM4IV64BMKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6SRKIQ#issuecomment-530912546, or mute the thread https://github.com/notifications/unsubscribe-auth/ABT3UKVIM6KGLRBSOK5AMG3QJJXYBANCNFSM4IV64BMA .
I found this buried in Azure's documentation (this should be part of the on-screen text on the Azure App Service control panel...):
https://docs.microsoft.com/en-gb/azure/app-service/deploy-ftp
- To disable unencrypted FTP, select FTPS Only.
- To disable both FTP and FTPS entirely, select Disable. When finished, click Save.
- If using FTPS Only you must enforce TLS 1.2 or higher by navigating to the SSL settings blade of your web app.
- TLS 1.0 and 1.1 are not supported with FTPS Only.
My Azure App Service was configured to use "FTPS Only" but also accepted TLS 1.0 connections (we have a lot of users that don't keep their computers updated... plenty of people on Windows 7 with IE11) - apparently this breaks Azure App Service FTP.
After changing the settings to allow insecure FTP, using FTPS using both Explicit and Implicit works fine. This is annoying because Azure would give me a warning message that the configuration is invalid.
Filezilla was working because it was defaulting to TLS1.2 by default, whereas FluentFTP was defaulting to TLS1.1.
While this addresses my issue, would you still like me to get answers to the questions you asked?
BTW, I noticed that when passing an incomplete FtpProfile
object to ConnectAsync
it causes an unexpected internal NullReferenceException
- the ConnectAsync
method should instead validate the FtpProfile
object and throw ArgumentException
if it's invalid.
Then let me also default to tls1.2, I don't think that should be too hard. Can you tell me the settings that work with azure out of the box and the final settings you used?
Can you also tell me the setup you are using with azure so I can build the same setup on my azure account and replicate these issues? Is it FTP with a VM with managed disks?
Defaulted to TLS 1.2 as far as possible.
Thanks for this.
Added your notes about Azure into the FAQ to help others - Thanks! - https://github.com/robinrodricks/FluentFTP#faq_azure
Client machine: Windows 10 x64 Remote FTP server machine: Azure App Service FTP publishing service (
WindowsServerIIS
)I used
await FtpClient.AutoConnectAsync()
and I noticed it took about 20 seconds to run before returning - and I saw it output a lot of details to the Visual Studio Debug Output window. I wasn't sure if it was meant to take that long because the auto-detect functionality in desktop FTP clients tends to only take a few seconds.I note that desktop FTP software tends to test each connection setting from most-to-least desirable order (i.e. FTPS+PASV first, and only trying another setting if the first attempt failed, whereas
AutoConnectAsync()
seems to try-out all connection settings all-at-once - which may cause problems with remote FTP servers that block successive new connections as protection against DDOS and password brute-force attacks.My thoughts and questions:
AutoConnectAsync
/AutoConnect
should try a limited number of "preferred" connection configurations and only brute-force through other configurations if no preferred connection configuration works.GetReply()
not being called when it isn't the responsibility of the caller ofAutoConnectAsync()
?Logs :
Here's what I saw in the Output window: