Right-Click to Calendar - Chrome ウェブストア
v3.10をリリースしました。ベータ版機能ですが、Edge (Chromium)対応をしています。
前の記事で書いたのですが、リダイレクト先のURLにchromiumapp.orgが登録できず詰んだため、 諦めてOAuth2.0のクライアント用サーバーを実装して、 この実装だとRight Click to Calendar以外のアプリケーションからもRight Click to Calendar用のアクセストークンとリフレッシュトークンが取得できてしまうため、v3.11で使用を中止しました。ダメ元で試したところretrorocket.bizに設置しました。実装したサーバーのソースコードは以下で公開しています。
rc-oauth2-client/main.go at master · retrorocket/rc-oauth2-clientchromiumapp.orgをリダイレクト先に登録できたため、v3.11以降はchromiumapp.orgを使っています。なぜ登録できるのかは特に説明がないので、ある日突然動かなくなるとかはありそうですね…。
サーバー側の処理を書いた後に気づいたのですが、リダイレクト先のURLにchromiumapp.orgを指定する方式だと、拡張のソースコード内にClient Secretを書き込むことになるので、最初からchromiumapp.orgを使う方式は難しかったかもしれません。
chromiumapp.orgを指定する場合、クライアントサイドでのフローになるためClient Secretは不要でした。
Client Secretを秘匿すべきかどうかは以下の記事で意見が出ています。
私は、「今後自分が作るアプリや作ったアプリに関しては漏洩してもリスクはゼロに近いが、可能であれば秘匿しておきたい」という結論です。こういう余計な事は考えたくないですし、取得したトークンの管理リスクも加味すると、やはりchrome.identity.launchWebAuthFlowは使いたくないですね。
拡張側のアクセストークン取得用の実装ですが、リフレッシュトークンをオプションページから初回の一度だけ取得し、あとはリフレッシュトークンを使ってアクセストークンを更新する方式をとっています。リフレッシュトークンとアクセストークンはlocalStorageに保存していますが、もうこれは仕方ないと割り切っています。 アクセストークンを更新する処理の実装はこのあたりに書いています。
Edge (Chromium)対応に関する不具合報告はGitHubからお願いします。Twitterやメールで聞かれても回答しません。スクショなしだと調査するのが難しいのと、調査コストに対して私へのリターン（金銭的なものではなくて、知識的な側面）が全くない機能だと思ってるためです。
また、おま環報告については基本的に調査しませんが、ご自身で調査してissueに上げていただければ可能な限り調査します。
動作確認は以下で行っています。
- Windows 11 pro, 10 pro 21H1, 10 pro 21H2
- Microsoft Edge バージョン 96.0.1054.62 (公式ビルド) (64 ビット)
- Vivaldi 5.0.2497.32 (Stable channel) (64-bit)