3

私は現在、かなり興味深い... プロジェクトに取り組んでいます。フォームのアップロード (サーバー上に表示されたページから) を、特に自分の Google ドライブ アカウントに許可したいクライアントがいます。使用されているプラ​​ットフォームは基本的に LAMP です。

単一の (事前認証済み) Google ドライブ アカウント。複数の匿名のアップロード ソース (ユーザー)。

彼らは、ユーザーが自分の Google アカウントを持つ必要があることを望んでいません (ユーザー自身のドライブ ファイルで Picker を使用することを除外します)。

彼らは、IE8 などのブラウザーの後方互換性をある程度望んでいます (ファイルデータを読み取るために HTML5 のファイル API を使用して投稿を形成する XHR を除外します)。特定のモバイル ブラウザとの互換性の問題が発生する可能性があるため、flash などを使用したくありません。

何が機能していますか:

  • 認証 (リフレッシュ トークンの取得、保存、必要に応じてそれを使用してアクセス トークンを取得する)
  • メタデータなしでアカウントにファイルをアップロードする
  • 非表示の iframe に送信されるファイル アップロードの結果
  • 少なくとも何かが起こったことを知るためにjqueryを介してiframeロードイベントをキャッチする

問題:

  • REST API アップロード エンドポイントは CORS をサポートしていません。結果の iframe に直接アクセスする方法はありません。(参照: JavaScript を使用した Google ドライブの認証)
  • アップロードが成功した場合の戻り値は、JSONP ではなく生の JSON のみです。
  • googleapis.com ドメインでブラウザ経由で開くための適切なヘッダーを持つものをホストする方法はないように見えるため、easyXDMやクロスオリジンの回避策を備えた同様のマルチ iframe 通信 JavaScript アプローチは除外されます。
  • 送信からの POST にコールバック URL を埋め込む方法はありません。API では許可されていません。
  • ピッカーは、ブラウザーでも認証されているユーザー用ではない Oauth2 トークンを渡すと、アップロードしようとするとエラーを表示します (おそらく Cookie を介して)。奇妙なことに、Oauth2 トークンの一致するアカウントからファイルを表示できますが、ターゲット Oauth2 トークンのアカウントが既にログインしているユーザーと一致するブラウザー インスタンス以外では、ファイルのアップロードはあいまいな「サーバーが拒否されました」というメッセージで失敗します。これは、認証されたブラウザ インスタンスで動作するファイルを含む、すべてのファイルとファイル タイプで発生します。ある種の認証フロー/スコープの問題だと思います。ピッカーソースをダイビングしようとはしていません。
  • すべての JavaScript Google Drive API アップロードの例は、HTML 5 を使用してファイル データを取得することに依存しているように見えるため、その性質のものは除外されているようです。ファイルがアップロードされている間、アクセスできない iframe の結果からファイル オブジェクト ID を取得できないため、どのファイルがどのユーザーからのものかを推測する以外に方法はありません。せいぜい非常に大まかな時間ベースの推測を行うことができますが、同時実行の問題が発生した場合、これはひどい考えです。
  • REST API は、フォーム フィールド経由ではなく、ポスト リクエスト本文の JSON 経由で送信されるメタデータに依存しているため、ファイル名やファイルのその他の識別子 (一意のフォルダーでさえも) を設定することはできません。そのため、名前などのないドライブ内のファイルオブジェクトになります。
  • 更新 API エンドポイントは PUT でのみ動作するため (テスト済み)、メタデータが入力されたサーバー側 (または jquery/XHR または Google JavaScript API クライアント経由) でファイルを作成し、フォーム ベースのアップロードで更新することはできません。
  • ファイルをローカル サーバーにアップロードしてから Google に送信する (プロキシする) ことはできません。これは、大きなファイルのアップロードを防ぐために php ini がロックされているためです (そして、HTML5 またはフラッシュの使用に課せられた制限に戻ることができない理由です)。チャンク ファイルなど)。

これらはすべて研究されており、さまざまな程度で試行されています。

現時点では保留中です (少なくとも、API を学習し、その制限を理解するのに役立つ方法でした)。ドロップボックスに同様のものを実装するつもりですが、誰かが有用な情報を持っている場合は、素敵なこと!

たとえば、ドライブでこれを機能させる方法はありますか? 私は何かを見落としましたか?

また、これはおそらく本質的に意図したユースケースではないことも認識しているため、奇跡は期待していません. 理想的なフローは、ユーザーが必要に応じて自分の Google ドライブにアップロードできるようにし、Web アプリへのファイル アクセスを (ピッカーまたは API + 独自の UI を介して) 許可することですが、そうでない場合はこれが問題になります。私たち自身のユーザーはすべて、必然的にすでに Google アカウントのユーザーです。これを実現するために、さらに多くの人にサインアップしてもらうことをGoogleが明らかに望んでいることは知っていますが、Googleアカウントにサインアップしてアプリを使用することは除外されました(私たちの偏見によるものではなく、追加の手順が多すぎて、潜在的なユーザーのハードルが多すぎました)。アカウントを持っている場合でも、単に Google にサインインさせるだけでも、基本的な LCD 機能の機能には不要であると見なされました。

4

1 に答える 1

1

あなたが説明したアプローチの最大の問題は、大きなセキュリティの問題を引き起こしていることです。匿名ユーザーがクライアントからドライブに直接アップロードできるようにするには、共有アクセス トークンを誰にでも漏らす必要があります。drive.file の範囲が限定されていても、悪意のある、または少し好奇心旺盛なユーザーは、そのアプリによってアップロードされた任意のファイルを一覧表示し、アクセス (読み取り/更新/削除) することができます。

もちろん、パブリック ドロップ ボックス機能は依然として便利ですが、アクセス トークンが明らかにならないように、これらのリクエストをプロキシする必要があります。PHP 環境の制限が厳しすぎる場合は、別の場所でプロキシを実行してみませんか? シンプルなプロキシをホストして、アプリエンジン、heroku など、ほぼどこでもアップロードを処理し、アプリのメタデータが正しく設定されるようにするために必要な機能をサポートできます。

于 2012-11-01T20:33:11.287 に答える