オフィスにいる間は、Slackのステータスを自動で会社の絵文字 🏢 にする ｜ Tips Note by TAM
TAM ではリモートワーク推進の取り組みをやっていまして、遠隔でのコミュニケーション方法や情報共有のやり方も、いろいろ試しながら模索していっている感じです。 オフィス以外の場所で仕事する機会が増えるとなると、「自分がいま出社しているのか、外で作業しているのか、休みなのか」をチームに上手いこと共有しておかないと、ですよね。その方法のひとつとして、Slack のステータス機能を試したりしています。 Slack のステータス機能 Slack のステータス機能は、こんな感じで絵文字とコメントを設定しまして、 Slack上では名前の横に絵文字として表示され、状況を共有可能です。オフィスにいる間は会社の絵文字 🏢 とかにしておくと良さそう？ ただ、これを手作業でちまちま変更するのは面倒くさいというか、毎日設定するのは絶対忘れてしまいますよね…… なんか自動化する方法はないもんか。 Slack のステ
SlackでOAuth2を利用したときのメモ - Qiita
Team パラメータを指定すると認可の確認画面に表示される 指定しない場合、ユーザが自身でteamを入力することになる 自身のアプリを登録する https://api.slack.com/applications の 「Create a new applicaiton」を押下 各種情報を入力して、「Create Application」ボタンを押下すると登録できる AppName, Team, Description, Redirect URIが必須 RedirectURIは、トークン取得時のリクエストに含める値と同じにする 登録が完了すると、client_id と client_secret が発行される SlackのOAuthを利用するアプリケーションが、正規のアプリケーションであることを確認するためのパラメータ 漏洩しないように注意 OAuthの仕組みを用いてSlackへの認可を得る
OAuthとOpenIDに深刻な脆弱性か--Facebookなど大手サイトに影響も
OpenSSLの脆弱性「Heartbleed」に続き、人気のオープンソースセキュリティソフトウェアでまた1つ大きな脆弱性が見つかった。今回、脆弱性が見つかったのはログインツールの「OAuth」と「OpenID」で、これらのツールは多数のウェブサイトと、Google、Facebook、Microsoft、LinkedInといったテクノロジ大手に使われている。 シンガポールにあるNanyang Technological University（南洋理工大学）で学ぶ博士課程の学生Wang Jing氏は、「Covert Redirect」という深刻な脆弱性によって、影響を受けるサイトのドメイン上でログイン用ポップアップ画面を偽装できることを発見した。Covert Redirectは、既知のエクスプロイトパラメータに基づいている。 たとえば、悪意あるフィッシングリンクをクリックすると、Faceboo
OAuth 2.0 の脆弱性 (!?) "Covert Redirect" とは - OAuth.jp
訂正 リダイレクト時の fragment の扱いを勘違いしていたため、本記事全体訂正します。 細かく訂正いれてると分けわかんなくなってきたんで、新しい記事書きました。 ゴールデンウィークまっただなかに Twitter で海外の ID 厨から袋だたきにあってたので、もうこの問題は片付いただろうとすっかり油断してた「Covert Redirect」の件ですが、日本でもゴールデンウィーク明けてバズりだしたので、一旦問題を整理した方がよさそうですね。 事の発端 Wang Jing さんていうシンガポールの大学院生が、こんなサイトを公開すると共に CNet はじめ各種メディアが取り上げたのが、バズりだした発端のようです。 前提知識 OAuth 2.0 や OpenID Connect だけでなく、OAuth 1.0 や OpenID 1.0/2.0 や SAML なんかでも、2つのサービスの間でリダ
Tender Surrender » OpenSocialのOAuthまとめ
OpenSocialでは、コンテナが外部サーバーとの通信を行う際、または外部サーバーがコンテナと通信を行う際、OAuthを使用して認可を行います。今回はOpenSocialにおけるOAuthについて、現段階でのまとめを書いてみます。 ※追記(2008/10/20)：2008/10/4に書いたコチラの記事も必読です。 OAuthって何だったっけ？ OAuthはユーザー、コンシューマ、サービスプロバイダの3者間でデータのやり取りを行うとした場合、ユーザーがコンシューマにクレデンシャル(IDやパスワード)を渡すことなく、ユーザーが所有するサービスプロバイダ上のリソースにコンシューマをアクセスさせるためのものです。 例えばユーザーがGoogle(サービスプロバイダ)のアドレス帳(リソース)をMySpace(コンシューマ)上で利用するシーンを思い浮かべてください。OAuthがなければ、MySpace
2-legged OAuth on OpenSocial - Codin’ In The Free World
OAuth Consumer Request 前回も簡単に触れましたが、OAuth Consumer Requestという拡張仕様があり、 これは二者間でのやり取りを行うためのものでした。OAuthのプロトコル中で 重要なパラメータは、トークンとシグネチャ(署名)です。トークンは、ある エンドユーザーがサービスプロバイダ上に持っているリソースに対して、 特定のコンシューマがアクセスしてもよいという認可を与えたという証明となります。 また、コンシューマはリクエスト毎に共有鍵、もしくは秘密鍵で署名をつけることにより、 不正なコンシューマの偽装を防ぐことが出来ます。 二者間でやりとりを行う場合、エンドユーザは登場しません。なので、トークンを 扱う必要がなく、署名の検証のみで認証を行うことになります。 事前にリクエストトークンの発行、エンドユーザをリダイレクトさせて承認をもらう、 承認済のリクエス
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ゼロから学ぶOAuth 記事一覧 | gihyo.jp