お世話になります。
BOXとの連携について検討しています。
BOX for kintone用のプラグインが、kintoneのサイト上にサンプルとして提供されていますので、そのソースを読んで改良しようと考えていました。 しかし、ソースを
読んでみて、同プラグインが自らの要件に合致していないことに気づきました。
それは、このプラグインがBOX内のフォルダのデータを、kintone内のフォルダに
コピーしているということです（自分でコードを読んだ限りは、そのように解釈しました。コピーは、kintone自体がバックグラウンドで行ってくれているようです）。 当方が保有するBOX内のデータは、サイズが大きいので、kintone内のフォルダにコピーすれば、kintoneのローカルストレージを大量に消費し、さらにコピーに時間を要するため、ユーザ・レスポンスが悪くなってしまうのです。
そこで、直接BOXの中のファイルにアクセスしようと考えましたが、クロスサイト制約に抵触してしまいそうです。 この場合、kintone.proxy()を使えば、問題解決できると考えてよいのでしょうか。
P.S
BOX for Kintoneでは共有リンクを使う旨、BOXへリクエストを発行していますが、kintone.proxy()を使っている形跡が、コード内に見当たりません。これは、kintoneとBOXの2社間で、コピーサービスを行う旨の協業がなされているからと考えましたが、間違っているでしょうか。 kintone.proxy()を使わずに、なぜ、両社間でコピーが行えるのか、メカニズムを教えて頂ければ助かります。 2社間で協業（提携）があるのだとしたら、その協業メカニズムを呼び出すためのインタフェースは、どこに記載されているのでしょうか。
一度に、いくつもの質問をして申し訳ありません。 すべてに回答を頂かなくても結構ですので、一部だけでもわかる方がいらっしゃれば、なにとぞ、ご教授をお願い致します。
よろしくお願い致します。
堀 兼光さん
cstapの瀧ヶ平です。
kintone.proxyを使わずに共有リンクを使える理由ですが、手元で通信を確認してみたところ、kintone.proxyメソッドではPOSTで
{
" __REQUEST_TOKEN__": "xxxxxxxxx",
"body":{...},
"headers":{},
"url": "http://example.com"
}
のような通信情報のデータを
https://subdomain.cybozu.com/k/(guest/){spaceid}/api/proxy/call.json?_lc=ja_JP&_ref=https://subdomain.cybozu.com/k/(guest/){spaceid}/{appId}
に対して送信しています。
これによってkintoneでは外部サイトとのプロキシ通信を可能にしているようです。
一方BOX for Kintoneプラグインのソースでは、XMLHttpRequestを直接利用し、先のURLにBOXとの通信情報を作成し送信しています。(desktop.js 99行目 syncApi メソッド)
つまり、BOX for Kintoneプラグインではkintone.proxyメソッドと同じことをXMLHttpRequestによって実行しているため外部サイトとのプロキシ通信をしていると考えられます。
なので、おそらく堀さんのおっしゃる通り直接kintone.proxyメソッドを利用して問題解決自体は可能かと思います。(実際には試していないので確認はしていませんが…)
以上、参考になれば幸いです。
瀧ヶ平さん、
ご返答頂きまして、有難うございます。
>つまり、BOX for Kintoneプラグインではkintone.proxyメソッドと同じことを
>XMLHttpRequestによって実行しているため
やはり、そのような解釈ですね。 当方の主観的な解釈かと思い、不安になって投稿させて頂いたのですが、大変、心強いです。
>直接kintone.proxyメソッドを利用して問題解決自体は可能かと思います。
>(実際には試していないので確認はしていませんが…)
当方にて、kintone.proxy()を使って、BOXとの通信が行えるかどうか、挑戦してみようと思います。 何か分かりましたら、本トピックにて、ご報告させて頂こうと思います。
ご協力頂きまして、まことに有難うございました。
堀
堀 兼光さん
お世話になっております。cybozu.com developer network 事務局です。
zipの中をのぞかれているのであれば既にお気づきになっているかも知れませんが、現在公開しているbox連携プラグイン（zendeskも同様）は、現状仕様を公開していないAPIを使ってリクエストをしております。
（このAPIを使わずkintone.proxy()を使っての連携は技術的に不可能な可能性があります。）
サイボウズとしてはプラグインの拡張をサポートすることはできませんが、ご参考いただければと思います。
事務局様。
返信頂きまして有難うございます。
＞現状仕様を公開していないAPIを使ってリクエストをしております。
はい、未公開のAPIを使ってリクエストされていることには気付いておりました。未公開部分というのは、cstapの瀧ヶ平様が指摘なさっている箇所だと思います。
現在、未公開となっている仕様が、将来、公開される予定はあるのでしょうか。
当方が検討中のプロジェクトでは、BOXとの連携が必須要件なのですが、御社で提供されているプラグインで要件が満たせない場合には、プロジェクト自体を見直さざるを得ません。公開等の、予定があるのでしたら、教えて頂ければ助かります。
＞（このAPIを使わずkintone.proxy()を使っての連携は技術的に不可能
＞な可能性があります。）
kintone.proxy()で連携できるかどうか調査中ですが、技術的に不可能となれば、ますます、非公開APIの公開化が重要になってきます。 ちなみにkintone.proxy()で技術的に不可能な可能性とは、具体的にどのようなものなのでしょうか。 想定があるのであれば、ご教授ください。
よろしくお願い致します。
堀
堀様
cybozu.com developer network 事務局です。
>現在、未公開となっている仕様が、将来、公開される予定はあるのでしょうか。
>当方が検討中のプロジェクトでは、BOXとの連携が必須要件なのですが、御社>で提供されているプラグインで要件が満たせない場合には、プロジェクト自体を見直さざるを得ません。公開等の、予定があるのでしたら、教えて頂ければ助かります。
将来的に実装される可能性はありますが、現状具体的な予定はありません。
>kintone.proxy()で連携できるかどうか調査中ですが、技術的に不可能となれば、ますます、非公開APIの公開化が重要になってきます。 ちなみにkintone.proxy()で技術的に不可能な可能性とは、具体的にどのようなものなのでしょうか。 想定があるのであれば、ご教授ください。
具体的な言及は避けさせていただきますが、認証周りでkintone.proxy()ではおそらく不都合が生じます。
よろしくお願い致します。