エンコード～アップロードがようやくできた。
ようやくエンコード～アップロードまでを実装することができた。アプリとしてはまだ道半ばではあるが。
ffmpegとYouTubeに必要なパラメータを入力してアップロードボタンを押すとffmpegでエンコード後アップロードされる。
下の動画は試しに実行してみたもの。
引き続いてWebGL/SVG/Canvasで動画を作ってエンコードする部分を作ろうと思う。この部分はエディタを作るというよりも、プログラムによって自動生成したものをキャプチャし、それを動画化するという方法でいこうかなと思っている。。だがエディタ的な機能は多少は必要となるだろうね。キャプチャ部分はnw.jsが持っているウィンドウのキャプチャ機能が使えるのではないかなと思っている。
クライアント・シークレットの隠ぺい問題
nw.jsでOAuth認証が必要なローカル・アプリケーションを作るときには常について回る問題。クライアント・シークレット（コンシューマ・シークレット）の難読化問題とでもいうべきか。何が問題なのかというと、クライアントIDとクライアント・シークレットが第三者にわかると私のアプリに成りすまして、OAuth認証ができてしまうという点。
デスクトップTwitterクライアントにおけるOAuth問題 - PowerShell Scripting Weblog
もちろんOAuth認証はユーザーが承認を与えないとリソースアクセスは許可されないわけで、私のアプリ以外は拒否ってくれれば安全は保たれるわけだが。
このようなことはメジャーなアプリになってから考えるべきなのかもしれないが、まあ気にはなる。実害としてはどのようなことが考えられるのか。
デスクトップTwitterクライアントアプリでOAuthを使うことの問題点？ - すぎゃーんメモ
Re: OAuth 2.0のclient_secretって本当に秘密鍵ですか？ - OAuth.jp
上記２記事を読むに私のクライアント・シークレットがしれた場合に起こり得ることは
- クライアントID・コンシューマー・シークレットをOAuthにより利用承認をしたユーザーに対して処理を行うことができる。たとえば私のアプリになりすましてYouTubeの利用承認したユーザーの動画をすべて削除したり、プライベートデータを読み取ったりすることができる。
である。
ローカル・アプリケーションではクライアント・シークレットを完全に隠ぺいすることは不可能である。
下はTwitterの公式デスクトップ・アプリが簡単にクライアント・シークレット（コンシューマ・シークレット）を抜き出せることを指摘した方が、逆に自分のアプリも抜き出されてしまったという話。
超軽量Twitterクライアント「もふったー」コンシューマシークレットキー難読化最後の挑戦 - GIGAZINE
クライアント・デベロッパーがとるべき道はできる限りクライアント・シークレットを難読化することと、定期的にクライアント・シークレットを変更するくらいしかないのか。
私は一応下記の対応をとることにした。
- 定期的にクライアントID・クライアントシークレットを変更する。新しいクライアントID・クライアントシークレットを発行したら、古いものは廃止する。
- 定期的にクライアントID・クライアントシークレットを変更するために、クライアント・シークレットはアプリには埋め込まず、サーバーからJSONデータとしてダウンロードする。サーバー側はUAをチェックし、私のクライアントからのみからアクセス可能とする。
- JSONデータは暗号化しサーバーに置いておく。クライアント側で復号する。
上記のようなことをしても、完全ではない。nw.jsのソースコードは容易に読むことが可能なので、すぐにわかってしまう。やらないよりは多少ましかなといった程度である。なのでソース・コードを公開するのをちょっとためらっている。