Que tipos ou padrões existem para (S) autenticação e uso de proxy FTP?

Question

Eu desenvolvo e suporto um programa que usa (S) FTP para baixar arquivos para servidores corporativos. Os clientes corporativos geralmente exigem que meu programa passe por um proxy em vez de se conectar diretamente. Infelizmente, os proxies (S) de FTP não parecem ser padronizados, particularmente em relação à autenticação.

Gostaria de encontrar uma maneira padrão de interagir com um proxy (S) FTP, sem conhecer o fornecedor antecipadamente.

Se isso não for possível, gostaria de reunir uma lista dos diferentes (S) tipos de proxy FTP, seus prós e contras (se eu tiver uma escolha sobre qual usar), como usá-los, exemplos de fornecedores implementá-los, links para mais informações, etc.

    

Answer 1

Aqui está o que eu encontrei até agora:

• Sintaxe de login do ponto de verificação
  • Trabalhos para FTP
  • Funciona passando informações extras ao proxy por meio dos comandos USER e PASS.
  • Como nenhum comando especial é necessário, todos os programas com reconhecimento de FTP devem poder usar esse método, mesmo que não tenha noção interna de proxies. Você acabou de alterar o usuário / passe que ele usa.
  • USER: ftp_username @ proxy_username @ ftp_host
  • PASS: ftp_password @ proxy_password
  • Usado por: Bluecoat ProxySG, provavelmente outros.
  • Mais detalhes: link
• Sintaxe de login do Raptor
  • Trabalhos para FTP
  • Semelhante ao ponto de verificação, exceto que a senha do proxy é passada usando o ACCT.
  • Requer que o programa entenda o ACCT, mas separa as senhas que podem ser preferíveis. Suporta o caractere @ na senha, ao contrário do ponto de verificação.
  • USER: ftp_username @ ftp_host proxy_username
  • PASS: ftp_password
  • ACCT: proxy_password
  • Usado por: Bluecoat ProxySG, provavelmente outros.
  • Mais detalhes: o mesmo link acima (o SuperUser me limita a 2 links)
• SOCKS
  • Funciona para qualquer protocolo
  • O SOCKS é um protocolo de proxy padronizado.
  • O SOCKS pode ser usado não apenas para FTP, mas também para protocolos completamente diferentes.
  • Se um programa entende e pode usar o SOCKS, esta é provavelmente a solução mais flexível. No entanto, a implementação pode ser mais complicada.
  • Mais detalhes: SOCKS na Wikipedia
• HTTP CONNECT
  • Trabalhos para FTP
  • Comece com uma conexão HTTP para um servidor proxy. Uma vez que a conexão através do proxy é estabelecida, o TCP ainda é usado, mas o cliente é livre para mudar para outros protocolos (como o FTP).
  • Esta pode ser a opção mais fácil e flexível. Uma desvantagem é que o programa deve suportar o protocolo HTTP para o CONNECT inicial, além de seu suporte FTP.
  • Mais detalhes: link
• Outros métodos referenciados no Filezilla. Ainda não encontrei explicações para estes.
  • USER @ HOST
    • Ordem de comando (vírgulas não literais): USER% s, PASS% w, USER% u @% h, PASS% p, ACCT% a
  • SITE
    • Ordem de comando (vírgulas não literais): USER% s, PASS% w, SITE% h, USER% u, PASS% p, ACCT% a
  • ABERTO
    • Ordem de comando (vírgulas não literais): USER% s, PASS% w, OPEN% h, USER% u, PASS% p, ACCT% a
• Lista de fornecedores
  • Consulte o link .
  • Isso não fornece detalhes de implementação, mas ajuda a entender o intervalo de ofertas. Penso que os Secure Web Gateways são um superconjunto de proxies (ou seja, oferecem outros serviços como remoção de malware, provavelmente monitoramento). Normalmente, quando você passa por um proxy corporativo, será um desses SWGs.