Slack App対応

[kei1107]

https://api.slack.com/authentication/migration

[kei1107]

SocketMode接続 : https://api.slack.com/methods/apps.connections.open

app_tokenはconnections:writeを付与したapp-level token（not bot-level token)でxapp-xxx-yyy形式のもの

    Ok(reqwest::blocking::Client::new()
        .post("https://slack.com/api/apps.connections.open")
        .header(AUTHORIZATION, format!("Bearer {}", app_token))
        .header(CONTENT_TYPE, "application/json")
        .send()?
        .text()?
        .parse()?)

response example

{
    "ok": true,
    "url": "wss://wss-somethiing.slack.com/link/?ticket=12348&app_id=5678"
}

[toru-fukaya]

今のsanacaの設計的にevent apiは使えないんですよね。何故かというとevent apiはclientが複数あったときに1つ以上に通知があることしか保障してくれませんが、全部に通知がある前提で作っているので。

https://api.slack.com/apis/socket-mode#connections

When multiple connections are active, each payload may be sent to any of the connections. It's best not to assume any particular pattern for how payloads will be distributed across multiple open connections.

[vorj]

本当に分散システムにしてしまう(各sacana同士が通信しあう作りに変える)の，とても(たいへん)面倒(たいへん)なのでやりたくない

[kei1107]

今のsanacaの設計的にevent apiは使えないんですよね。何故かというとevent apiはclientが複数あったときに1つ以上に通知があることしか保障してくれませんが、全部に通知がある前提で作っているので。

確かに...応答しなければ3回まではリトライしてくれそうですが...............

https://api.slack.com/apis/events-api#retries

[vorj]

そういえば知人から聞いた知見として，

• (bot/appに対して)動かす環境は1台にする
• アプリ側は sudoers で NOPASSWD に設定したbot用ユーザーで対象マシンにsshしてユーザーを作っていく

の作りでどうか，という話を聞きました．動かしてるマシンの秘密鍵が漏洩したりしない限りは良さそう(漏れたら大事故だが :sorehasou: )なのと，全ての対象マシンに疎通できる箇所でアプリを動かさないといけない点がやっかいかなという気持ち

[kei1107]

https://api.slack.com/legacy/enabling-bot-users

Beginning March 31, 2025, we will discontinue support for legacy custom bots. For your integrations to continue working, you must create brand new Slack apps. Refer to this changelog article for more details.

😇

[kei1107]

社内より情報提供

CloudFlareが Pingora っていうProxyフレームワークをOSSにしたんだけど、通信のバックエンドにこれ利用できないかな?
単一のエンドポイントでslackのメッセージを受け取り、それを目的のサーバーに配送&応答を戻すので、Proxyサービスを作ることになるんじゃないかと考えました。

[toru-fukaya]

とりあえず年内対応くらいを目標とする。