“FTP-prokuro” povas priskribi pordegon, kiu mem parolas FTP. Konektiĝi al ĝi diferencas de peti HTTP-prokuron pri CONNECT aŭ peti SOCKS-servilon malfermi TCP-celon.

La pordego bezonas la celan gastiganton kaj konton, kaj eble unue bezonas sian propran ensaluton. Produktoj esprimas tiun konversacion diversmaniere:

AranĝoTipa komanda formo
Celo kodigita en uzantnomoUSER target-user@target-host
Aparta pordega ensalutoPordega USER/PASS, poste la cela ensaluto
Klara celkomandoSITE target-host aŭ OPEN target-host, poste la bezonata ensaluto

Ĉi tiuj estas familioj de konvencioj, ne unu norma sinsekvo por ĉiu pordego. Elektu la metodon dokumentitan de la administranto kaj subtenatan de la kliento.

Tenu ambaŭ kontojn videblaj en la agordo

La cela FTP-pasvorto kaj la pordega pasvorto povas malsami. Iuj pordegoj kunigas ilin en unu USER/PASS-prezenton; aliaj postulas apartajn interŝanĝojn. Meti ĉiun valoron en unu ĉenon ne povas reprodukti klienton, kiu devas sendi pliajn komandojn.

Ĉi tio klarigas utilan limon en malnova FtpWebRequest-kodo. Ordinara FTP-konekto al la pordego, kun pordega uzantnomo, povas taŭgi por iuj USER/PASS-aranĝoj. Pordego postulanta apartan SITE- aŭ OPEN-konversacion bezonas klienton, kiu efektive subtenas tiun fluon. La eco Proxy de WebRequest estas denove alia interfaco.

WinSCP, ekzemple, prezentas apartajn FTP-prokurajn ensalutmetodojn anstataŭ trakti ĉiujn pordegojn kiel unu gastigantan kampon. Ĝiaj numeraj krudaj agordaj valoroj apartenas al ĝia dokumentita API; uzu la metodnomon kaj la celatan konversacion kiam vi revizias agordon.

Post ensaluto, dosiertransporto ankoraŭ bezonas sian FTP-datenkonekton kaj la elektitan TLS-reĝimon. Sukcesa ensaluto sur la regkanalo estas la komenco de tiu vojo, ne pruvo, ke ĉiu datentransporto jam estas permesita.

Rilataj artikoloj