nyamadori/metabot

Slack bot execution environment

metabot's Issues

要件定義

技術

• Firebase Web hosting
• Cloud Firestore
  • bot の brain をスキーマレスで扱える
  • ドキュメントごとに認証をかけることができる
• Cloud Functions
  • bot の動作環境
• GitHub
  • bot のソースコード管理

ユーザフロー

bot ソース管理

フロー図

bot データ

ER 図

ドキュメント構造

{
  bots: {
    'pr-police': { // bot 名は Slack 上からコマンドを呼び出すときに使うのでユニークであって欲しい
      sourceUrl: 'https://xxxxx.com/metabot/pr-police/packages/latest.zip',
      channels: {
        '#ieul-dev-deploy': true,  // チャンネル内の全員が利用できる場合
        '#ieul-dev': { // チャンネル内で利用できるユーザを絞る場合
          '@manabu.nakajima': true,
          '@xxx.yyy': true,
        },
      },
    },
  },

  brains: {
    id_1: {
      bot: 'pr-police',
      channel: '#ieul-dev',
      body: {
        remindAt: '10:00 am',
        repositories: [
          'speee/im-ieul-core',
          'speee/im-ieul-lp',
        ]
      }
    },
  }
}

要求定義

やりたいこと

社内ユーザが Slack bot を作り、作った Slack bot を誰もが自由に利用できる仕組みを作りたい。

課題

• ボットの実行環境を用意する必要がある
• ボットの記憶領域（brain）を用意する必要がある
  • 様々な Slack ユーザやチャンネルでボットを自由に使えるようにするには、brain にスコープが必要
  • ボットごとにスコープの仕組みを実装するのはバカらしい
  • スコープは、ボット作者ではなく、ボットを利用するユーザが決められるようにしたい
• 作ったボットを一覧化し、検索できる仕組みがない

要求

• 作ったボットを一覧化し、検索できる Web ページ
• ボットの実行環境
  • ボットが数百あっても、シュッとたちががる仕組み
  • ボットごとに環境が分けられていて、他のボットの実行を邪魔しない
• ボットの記憶領域
  • brain のスコープをユーザごとに決められる
  • ボットの作者が brain のスコープを実装しなくて良い

インストールコマンド

概要

• 誰かが開発したボットを使えるようになる
  • bot の Git リポジトリを指定すると自動でコードのビルドとインストールを行う

TODO

• install コマンドを作成
• [ ] コードのビルド（Webpack など）を行う処理
  • function 内でタイムアウトになるので断念
• [ ] ビルドしたファイルを Firestorage にアップロードする処理
  • 時間的に断念
• アップロード通知を行う処理

Slack からのメッセージをもとに brain を取得する

概要

• Bot の記憶領域である bot を Slack メッセージから取得する
• 受け取ったメッセージから、メッセージを書いた channel、user を得る
• command、channel、user の組み合わせから、モックとして Firestore に用意した brain を取得

Todo

• Firestore にモックデータを用意する
• Slack のメッセージから command、channel、user を得る
• command、channel、user から brain を取得

Slack からのメッセージを受け取る

概要

• /meta invite slack slash command に応答する
• /meta --help でコマンドのヘルプテキストを返す

Todo

• yargs でコマンド引数をパース

firebase-admin じゃないほうのクライアントライブラリが cloud functions 上で動くか

結果: 動いた

背景

• Cloud Firestore で brain ごとに認証を行いたい
  • そのためには firebase-admin じゃないほうのクライアントライブラリが cloud functions 上で動く必要がある
  • 言い換えると、通常 cloud function はサーバサイドなので特権ユーザだが、metabot は、ユーザ定義のプログラムが cloud function 上で動くので、function は特権ユーザで動くと困る

yargs の command ディレクティブを使わないようにする

非同期 command をうまく実行できないので、yargs をコマンドのパースだけに使う。command の呼び出しを独自で行うようにする

ユーザ定義プログラムから入力されたコマンドに必要な brain 以外の brain は取得できないようにする

概要

• bot の開発者が作ったプログラム（=ユーザ定義プログラム）から、入力コマンドに必要な brain 以外の brain は取得できないようにする
  • ユーザ定義プログラムが他の bot の brain を書き換えることを防ぐため

手段

• Firebase Admin SDK によって、好き勝手データを書き換えられることを防げばいい
  • Firebase プロジェクトを、Slack イベントを受け取り Bot のデータを管理する部分と、ユーザ定義プログラムを実行する部分とに分割
  • 前者のプロジェクト（metabot プロジェクト）は、Firebase Admin SDK で自由にデータの読み書きができるが、後者（metabot-exector プロジェクト）はそもそもプロジェクトが異なるので、�明示的にサービスアカウントを用意しない限り、Bot のデータを自由に読み書きができない
  • Bot データを管理する metabot プロジェクト側は、目的が実現できるよう適切に Firestore セキュリティルールを適用
  • metabot-exector からは Firebase クライアント用ライブラリを使い、metabot プロジェクトの Firestore にアクセス

Todo

• プロジェクトの分割
• brain のモックデータに適当なトークン（Brain トークン）を追加
• metabot-exector が認証するエンドポイントを metabot 側に 用意
  • https://firebase.google.com/docs/auth/admin/create-custom-tokens?hl=ja
  • 認証は brain トークンで行う
  • レスポンスは Firebase Auth のカスタムトークンと Bot の情報
    • 実際にはユーザ定義プログラムとかを送ったりする
• Brain トークンで認証されていないと brain データが見られないようにセキュリティルールを記述