Názor k článku Chrome a Firefox tlumí podporu FTP a plánují ji úplně ukončit od Petr M - Normální deploy = otestuju na testovacím mirroru, uploaduju. Z...

Normální deploy = otestuju na testovacím mirroru, uploaduju.

Z pohledu souborů je jedno, jestli si ten produkční stroj namontuju po NFS, SSHFS, SMB,..., naklopím to tam RSYNCem, FTP, SFTP, FTPS, WebDAV, nebo pomocí hooku na merge do protukčního banche v GITu uděláš automaticky upload na produkční stroj,... Tam jde o to dostat tam fyzicky soubory. Z toho pohledu jde o styl práce.

Z pohledu bezpečnosti (a legislativy) tam ty soubory potřebuješ dostat tak, aby je nikdo nezměnil ani cestou, ani pozděj bez schválenýho přístupu.

Co se týká změn cestou, šifrování je nutnost. Takže šifrovaný přenos, nebo nešifrovaný ve VPN. Tzn. bez VPN je FTP mimo hru z tohohle pohledu.

Co se týká změny potom, server musí dovolit nahrávání jenom tomu, kdo se mu autorizuje. U prostýho FTP je to kdokoliv, kdo má přístup ke komunikačnímu kanálu a jednou viděl začátek komunikace. U FTPS záleží na implementaci, mám pocit, že je i taková, která napřed naváže klasický FTP spojení a pak domlouvá šifrování jenom pro data. To je taky blbě.

U SSH/SSHFS/SFTP mám šifrování (= žádná změna během přenosu) + dvoufaktor (mám klíč, vím k němu PIN) a RSAčko je dost odolný, aby ho 99,999% nelousklo během desetiminutové komunikace se serverem. Takže znovu - jakou výhodu má FTP(*)?

(*) OpenSSH je pomalý, ale kolikrát denně děláš deploy webu a kolik TB tam ty JavaScripty/CSS mají?

WGET v CRONu je trochu extrém, ale je to ukázka, že obejít se dá cokoliv a udělat to jakkoliv, i absence rozumnýho protokolu ze strany poskytovatele webu nemusí být problém. Lepší je ale nevybírat si hosting levnější než nejlevnější garážovku, ale podle parametrů. Jeden z parametrů jsou možnosti správy a deploye.