HrsTのあれこれ

Slack Enterprise Grid それはSlackの最上級のプラン。 ワークスペース作り放題なのでMicrosoft Teamsライクな使い方が出来る。 データのエクスポートはDiscovery APIとして提供され，プラスプランで提供されているCorporate Export は提供されていない。同様の作業は”セルフ”になる。 なんで提供してくれないんだろう？と文句をSlackに言ったことはあるけどね。 Discovery APIを使うためにはいくつかの手順があるのでそのメモ。Slack担当者に聞けば答えてくれるし，Grid契約の前に説明があると思うけど，その前に知りたい人向けってことで。 １．開発用環境をSlack担当者に依頼する もちろん，プランはEnterprise Gridなのですべての機能を試せる 設定を試すとか，アプリのテストも出来るよ ２．Discovery APIを使用するためには本番と開発環境で有効化する必要がある。 まずは，開発環境で有効化しよう プライマリオーナーにDiscovery APIのドキュメントが公開される もらったURLからしか開けないので忘れないようにしよう。 ３．アプリを作成する 作成したアプリのScopeにDiscovery APIを追加依頼を出す scopeの選択肢には表示されないので，間違って消したら再申請？ アプリはオーガニゼーションにインストールしTokenを取得する 手順書はもらえる。ドキュメントにはなかったと思う。 ４．Discovery APIを使って実施したい操作をする 公開されているSlack APIのつよつよ版なだけなので普通のAPIと一緒。 検索すればサンプルはいくらでも出てくるのでそれを参考にしよう。 当然だけどDiscovery APIのサンプルは出てこない ５．すべての情報を取得できるので，取得した情報の取り扱いは注意する 「通信の秘密」に該当する情報だと思うのでね。 依頼する手続きは最初以外は「/feedback」コマンドでよいのが楽で良いですね。 ちなみに/feedbackは9時～5時以外は英語の対応になるってのがグローバルって感じです。 DiscoveryAPIによるエクスポートで優れているのは，フルカスタマイズ可能なこと 特定期間だけのエクスポートは

PowerShellの情報って少ないよね～Windows10だと標準で動作するのでもっと情報が増えても良いと思うんだけど。 今日は，ダイレクトメッセージを保存しておきたいな～とふと思ったときに使えるスクリプトを招待するよ。チャンネルの取得も同じなので色々と使いまわしが出来るので覚えておこう。この記事の売りはもちろん，Pythonやcurlコマンドではないのですぐ使えるよ。 初めてWeb APIを触ったときはPython勉強しないとダメ？とかcurlコマンドで動くことは分かったけど次はどうすれば？って困ったんだけど，curlコマンドをPowerShellで記述できれば開発環境はWindows10標準のPowerShell ISEで十分なので困ることも少ないよね https://api.slack.com/apps を開いてSlack appを作るけど，必要なUser Token Scopesは「im:read」と「im:history」と「mpim:read」と「mpim:history」だね。 添付ファイルも取得するなら「file:read」が必要。 アプリをインストールしたらOAuthトークンが手に入るので変数「$OAuthToken」に入れておこう。 $OAuthToken = "xoxp-XXXXXXXX" ダイレクトメッセージを取得する準備としてチャネルIDを取得しないといけないので，次のスクリプトを実行する。今回は1対1のみを指定したよ。 3人以上のダイレクトメッセージならUriのtypes=をmpimに変更しよう。 成功したら ok : true,～って感じに表示されるよ。 $param = @{     Uri = "https://slack.com/api/conversations.list?types=im"     headers = @{         Authorization = "Bearer " + $OAuthToken     }     Method = "GET" } Invoke-RestMethod @param | ConvertTo-Json メッセージを取得する時は，下のスクリプトを実行するよ。 大切なのはさっき得られた結果の「id:

  注意：個人的な見解です。 顧客情報が漏洩したとき，「パスワードは暗号化されており問題ない」と説明を聞いたことが有るのですが， パスワードを暗号化した文字列なら問題無いかな？ でも，パスワードをハッシュ化した文字列だと大問題ですよね。 パスワード「P@ssword」をそのまま保存して，認証時に一致しているかを確認するシステムなんて今どき存在しないと思いたいですが，ハッシュ化して「28s5g3s」を保存してユーザーが入力したパスワードをハッシュ化して一致するかを確認するのは一般的かな？（ハッシュ化を暗号化と表現し漏れても問題ないって人はいます） パスワード欄に「P@ssword」と「28s5g3s」どちらを入力しても認証成功するSMTPサーバ知ってますけど，この製品だとどっちが漏洩しても問題ないとは言えないですよね。 ハッシュ化って非可逆性の変換する仕組みなので「A」を「abc」変換できるけど，「abc」から「A」を断定することが出来ない。「abc」に変換できる文字は「A」や「F」や「GT」など複数あることはわかるけど，「A」であるとは断定できない。だから利用者が入力したパスワードが分からない。だけど，保存しているハッシュ化パスワードと一致するので認証成功できる。 利用者が入力した「P@ssword」を守る効果はあるけど，それに何か意味があるのかな？ 入力されたパスワードを無加工でハッシュ化するシステムなんて存在しないと思いたいですね。

 注意：個人的な見解です。 よく，パスワードを強化しろ！使いまわすな！ってきくけど，認証する側がしっかりしてれば適当なパスワード(1111)でも統一でも良いのでは？って思うことが有ります。 秘密の文字列一つで守るって何やっても弱いですよね。 実際のところ認証する側が漏洩事件を起こしたり巻き込まれたりするので全くダメなのですが・・・ そもそも，おまえに認証されたくないのですが！！ おまえは認可だけしてろよ！！ って。認証と認可って言葉を使ってみたかっただけです。 TwitterやFacebook，Google，Microsoftアカウントは多要素認証にも対応しているので彼らに認証を任せて，連携してくれればな～と本心から思います。 多要素認証ってパスワード自体が脆弱でも問題ないって思うんですよね。ただ，一つのデバイスで多要素認証する場合はほぼ意味ないですけど。 多要素認証の良いところって，誰かが勝手に自分の認証を行ったときに通知が来るところなんですよね。「あなたのID,パスワードが漏洩しました」って言われても，多要素認証で利用するデバイスが手元にあれば拒否すればいいのです。そしてパスワードを変更すれば解決です。 もうね，多要素認証に対応しない認証なんて悪の組織の一員か？って思ったりしてます。 認証のシェア3割目指すとか考えていないなら，認証連携機能を搭載してほしいな～と思います。 パスワードを保管するってリスク以上のメリットってないと思いますよ。