HTTPS Webアプリケーションを介したファイルのアップロード
クライアント向けのWebサイトがあります。ログインページにアクセスするには証明書が必要です。この場合、さらにログインするにはusernameとpasswordが必要です。システムには、ロードバランサとして機能するApacheサーバーがあり、次にアプリケーションを提供するTomcatサーバーがあります。これまでは問題ありませんが、ユーザーがアプリケーション内の設定の構成変更を一括アップロードできるファイルアップロード機能を提供したいと思います。
最善のアプローチについて何か考えはありますか？既に確立され認証されているHTTPSリンクを介して、本当のSFTP接続を確立することは可能ですか？そうでない場合、どのように？考え？
すでに確立され認証されているhttpsリンクを介して、本当のSFTP接続を確立することは可能ですか？
はい、サーバーとクライアントのHTTPS実装を書き換えて、カスタムSFTPクライアントを作成し、異なるプロセス間でソケットを共有する問題を解決するとします。
ファイルのアップロード にHTTP（over SSL）を使用しないのはなぜですか？
SFTPは別のプロトコルです。 SFTPは [〜＃〜] ssh [〜＃〜] を介して構築されています（正確には、SSHでも使用されるトランスポートプロトコルを介して）。あなたは [〜＃〜] ftps [〜＃〜] について考えるかもしれません、これはFTP-with-SSLです。ただし、同じSSLセッションでHTTPトラフィックとFTPトラフィックを混在させる簡単な（または難しい）方法はありません。
安全で認証済みのHTTPSセッションを確立する問題に直面した場合、私のアドバイスはそれを使用し、Webベースのアップロードシステムを提供することです。単一のファイルのアップロードは 簡単 です。一括アップロードの場合は、より豊富なユーザーインターフェイス（多くのファイルを選択し、ディレクトリを再帰的にアップロードするなど）が必要になります。そのためには、クライアント側にいくつかのコード（Javascriptではなく、完全なコード）が必要です。ローカルファイルへのアクセス）。既存のWebセッションを再利用するのはちょっとトリッキーです（たとえば、ローカルコードが署名済みのJavaアプレットの場合、そのアプレットはファイルの内容をJavascriptコードに渡す必要があります。次に、ブラウザーを介してアップロードを実行します。基本的なグーグルポイントは、ActiveXコントロールである CuteUpload を指します（したがって、Windows + IEに限定されます）。署名済みのJavaアプレット）これは、サーバーへの接続を開き、（ブラウザを使用する代わりに）認証自体を実行します。この時点で、必要な処理を実行します。これが実際に適用できるかどうかあなたの正確なコンテキストに依存します。
証明書ベースのクライアント認証システムがすでにある場合は、安全なチャネルがすでにあります。その組み合わせにSFTPを追加してもセキュリティは向上しませんが、複雑さが増し、攻撃対象が拡大します。
ただし、1つ質問があります。証明書ベースのログオンを要求した後に、ユーザー名とパスワードが必要なのはなぜですか。