Google Drive APIを使用する機能

最近、Googleドライブ用のシンプルなアプリを作成する必要がありました。 アプリケーションは、指定されたフォルダ内のドキュメントが編集の可能性で共有されたユーザーのリストを形成することになっています。 タスクは原則としてシンプルなので、考え直すことなく、angularJSにプロジェクトブランクをデプロイし、コーディングを開始しました。 Googleは大企業だと思っていたので、わかりやすく安定したAPIを備えている必要があり、数日中にそれを行う予定です。



私はあまりにも素朴でした。

ログイン

アプリケーションは、サーバー部分（クライアントjsのみ）が存在しないことを暗示していたため、認証と識別のために、Google認証を使用することが決定されました。 ログインは簡単です！ しかし、そこにありました。 アプリケーション画面間でユーザーを識別するために、彼はgapi.auth.getToken（）メソッドによって返される認証オブジェクトを保存することにしました。 通常の方法、すべてがこのために作成されたかのようです。 しかし、このオブジェクトをシリアル化するとき、「プロパティ 'toJSON'へのアクセス許可が拒否されました」という面白いエラーが常に発生していました。 このエラーは「直感的」に理解できるため、半日費やしました。 この関数が返すオブジェクトには、それ自体への循環参照があることがわかりました。 ループバックリンクはg-oauth-window変数に含まれていました。 そのため、単純なコードでこの問題を解決しました。

var oAuthObj = gapi.auth.getToken(); oAuthObj['g-oauth-window'] = null; $window.localStorage.setItem('googlerSession', JSON.stringify(oAuthObj));
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

クライアント認証の次の問題は、クライアントセッションの再開です。 クライアント認証のみを使用した認証セッションは1時間保存されます。 しかし、それを更新または拡張する方法は明確ではありません。 再承認やその他のシャーマニズムを伴うタンバリンとのダンスは私を助けることができなかったので、今までクライアント部分は私を1時間承認しました。 便宜上、セッションの無効化までの残り時間をトップメニューに追加しました。 このツールでは、原則として1時間で十分です。

ドキュメントを操作する

そして、いくつかの問題がありました。 最初に遭遇した問題は、ドキュメントへの外部リンクを取得する方法でしたか？ すべてが通常のドキュメントで問題ない場合-ファイルオブジェクトのalternateLinkプロパティから取得される場合、フォルダにはいくつかの魔法があります。 フォルダーは、これまで見たことのない奇妙なfolderviewインターフェースへのリンクとして返されます。 グーグルは何にもつながりませんでしたので、Iいコードで修正する必要がありました：

 var fileLink = fileObject.alternateLink; if (fileLink.indexOf("folderview") != -1) { fileLink = fileLink.replace("folderview?id=", "#folders/"); fileLink = fileLink.replace("&usp=drivesdk", ""); fileLink = fileLink.replace("docs.google.com", "drive.google.com"); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

文書の権利

Googleに提供するuserIdに関してドキュメント所有者の配列全体を作成しました。 私はそれがユニークだと思い、これが同じユーザーであるという完全な理解を与えました。 しかし、これは事実ではありませんでした。 drive.permissions.listのドキュメントによると、ユーザー識別子（ proflink ）はidとして返されます。 しかし、実際には、これは私が探している識別子ではないことがわかりました。 なぜこれなのか-私にとってはまだ謎のままです。 そのため、私はメールを使用して所有者のリスト内のユーザーを特定し、「認識」しました。 しかし、これはまだ問題の半分です。



識別子とのこの混乱は、別の面白いバグにつながります。 現在の許可ユーザーがドキュメントの読者である場合、permission.listはアクセス権のリストを返しません。 したがって、私が読者であることを示すために、現在のユーザーのuserInfoからの情報を使用します。 そして、同じ人物が別のファイル（たとえば、ドキュメントの所有者）のpermission.listにある場合、彼は完全に異なる識別子を持ちます。 これにより、ユーザーのリストで現在の承認済みユーザーを複製できます。







結論：ユーザーIDは変更される可能性があるため、信頼できません。 電子メールを使用してユーザーを特定することをお勧めしますが、理論的には存在しない場合もあります。 たとえば、ドキュメントが企業ドメインと共有されている場合、この場合、このドメインに属するすべてのユーザーと共有されるため、電子メールはありません。



私の頭からすでに飛び出した小さなものがいくつかありました。 たとえば、ファイル情報を含むオブジェクトには、ドキュメントに記載されているいくつかの変数がありませんでした。 正直なところ、私はどれを覚えていませんが、これらは些細なことです。



PSこのすべてから来たものはここで観察することができます 。 サービスを補完する方法についてアイデアがある場合は、コメントを書いてください-私はそれを実装します。



PPS記事に記載されている問題の美しい解決策を知っている場合は、個人的なメッセージまたはコメントに書いてください。 これらの問題に遭遇したのは私が初めてではないと思います。