DirectCloud-BOX APIを実行するまでにハマった事と感想

# DirectCloud-BOX APIを実行しようとしてハマった事を書き溜めます。

私の技術及び、ドキュメント読解力がないためか、結構ハマったので次にトライする人のためになればと思い書き記します。
キャンペーンや時期によって条件や改修が行われている可能性があるため、本記事の投稿日、更新日を考慮の上お読みください。
また、[DirectCloud-BOX のAPI連携により広がるファイル共有・活用の可能性 - 開発～利用までの期間短縮、業務の効率化を実現しよう！](https://qiita.com/official-events/64ff6ba4e653a822fce9)　が開催中です。

# ハマった事

## ドキュメントの記載間違い① service, service_keyの発行手順に間違いがある

[アクセストークンの発行](https://directcloud.jp/api_reference/detail/%E3%83%A6%E3%83%BC%E3%82%B6%E3%83%BC/Auth#%E3%82%A2%E3%82%AF%E3%82%BB%E3%82%B9%E3%83%88%E3%83%BC%E3%82%AF%E3%83%B3%E3%81%AE%E7%99%BA%E8%A1%8C) に

> service, service_key service、service_keyの発行につきましては、お問合せ窓口よりご連絡ください。

とあったため、問い合わせたが
![スクリーンショット 2021-08-13 13.42.02.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/180411/95add9ec-a0c2-cf2b-460d-eb91c371bfbf.png)

管理画面のここから出力できるとの返信を貰った。ここからすぐにAPIが利用可能:+1:

## [APIドキュメント](https://directcloud.jp/api_reference)にAPIエンドポイントの記載がない

APIのパスは記載されているが、プロトコル、ドメイン、接頭パスなどの情報が記載されていなかった。
力技（辞書総当たり）で探索した結果、**https://api.directcloud.jp/** にAPIパスをくっつけると動作する事がわかった。

## jsonBodyでリクエストすると失敗する

postmanで検証していたのですが、form requestだと通るようです。

## ドキュメントの記載間違い② langのデフォルト値がjpn＆＆設定効かない

些細な問題だが、[アクセストークンの発行](https://directcloud.jp/api_reference/detail/%E3%83%A6%E3%83%BC%E3%82%B6%E3%83%BC/Auth#%E3%82%A2%E3%82%AF%E3%82%BB%E3%82%B9%E3%83%88%E3%83%BC%E3%82%AF%E3%83%B3%E3%81%AE%E7%99%BA%E8%A1%8C)によるとデフォルトがengのようだが実際はjpnで返ってくる。
また、headerにlangを設定しても反映されない。試行錯誤の結果、headerではなくクエリストリングで追加すると動いた:+1:


## ドキュメントの記載間違い③ ブラウザを変えてもアクセストークン使えるよ

[アクセストークンの発行](https://directcloud.jp/api_reference/detail/%E3%83%A6%E3%83%BC%E3%82%B6%E3%83%BC/Auth#%E3%82%A2%E3%82%AF%E3%82%BB%E3%82%B9%E3%83%88%E3%83%BC%E3%82%AF%E3%83%B3%E3%81%AE%E7%99%BA%E8%A1%8C)には

> 新規発行されアクセストークンはセキュリティのため60日間のみ有効です。有効期限切れのアクセストークンは破棄され、新規に発行されます。アクセストークンは接続環境毎に発行されますので、例えば、chromeで発行されたアクセストークンはIEでは使用できません。


と書いてある。しかし、実際のところアクセストークンさえ発行すれば、ブラウザは関係ない（そもそもPostman/curlで発行しているのでブラウザではない）。
AWSALBというクッキーが書かれるので、おそらくスタティックロードバランサーに配慮したクッキーへの記載だろうと推測するが、アクセストークンには関係なかった:+1:

## ドキュメントの記載間違い④ requiredって書いてあるけど実はoptional

[フォルダリストの照会](https://directcloud.jp/api_reference/detail/%E3%83%A6%E3%83%BC%E3%82%B6%E3%83%BC/Folder#%E3%83%95%E3%82%A9%E3%83%AB%E3%83%80%E3%83%AA%E3%82%B9%E3%83%88%E3%81%AE%E7%85%A7%E4%BC%9A)によると、nodeは必須フィールドのようだが実際はoptionalで指定しなくても取得できる。
この事に気づくまで、WebUI上でどこからノードIDを取得できるか本当に悩んだ。（Chromeのネットワークタブから探した）
ひょっとして、と思いnodeなしでリクエストした結果、ルートフォルダからのフォルダリストの取得に成功した:+1:

---

# ここが惜しい！:cry: 

## アクセストークンを作成するのにID、パスワード、サービスシークレット（？）が必要

ユーザの生パスワードを貰わないと、アクセストークンが生成できない。
ユーザはサードパーティーアプリに生パスワードを渡す必要がある。そのパスワードが保存したり悪用されないかはサードパーティーアプリの開発者の良心に任される事になる。
一般的にはOAuthを利用して、生パスワードを渡さずに、サードパーティーアプリに権限を移譲するのが無難である。
また、サービスシークレットも必須なため、生パスワードを第三者のサーバーに送らないようにクライアントサイド実装したくとも、サービスシークレットを埋め込む必要がある:cry: 

----
追記
CORSがフルオープンだったので、サービスシークレット的なのは公開OKで、ブラウザ上で好きに使ってOKという事かもしれない。
（しかし、そうすると次項の問題がより顕著になる気がする）

## アクセストークンにスコープをつける事ができない

基本的にフルパーミッションのアクセストークンしか生成できないので

- 特定のディレクトリのみにアクセスできるサービス
- 書き込みだけできるサービス
- 読み込みだけできるサービス

のようなものができない:cry: （開発者のさじ加減ではできるが、ユーザが安心して使えるという意味でできない）
仮にアクセストークンが漏洩したときに、影響範囲が全ファイルに及んでしまうというのはサービス運営上のリスクになる:cry: 
また、開発者の良心に全てを任せる事になるため、スコープを設定できるとベター:+1:

---------
追記
これらの問題を回避するには、API連携用のユーザと共有フォルダを組み合わせてスコープを絞る必要があるため、利用開始時に手作業が発生する。
（ここを自動化するには管理者アクセストークン（スコープはなし）が必要）


# あとがき

私のスキルが足りないせいか、すごいハマってしまいましたが
SaaS提供者が、サードパーティの共有ストレージを使用できるという試みはS3やGCPと差別化できより良い。
反面、もう少しセキュリティ周りを調整できたらリトライしたいと思いました。