Slackで業務チャンネルの平穏を維持するbot、そして人間のトークンをbotに与える話 - Qiita
2016年もSlackが熱い一年でした！ ビデオチャット機能の追加や、Electronで一新された新クライアントの公開など、Slackの勢いはまだまだ止まりそうにもありません。 皆様も日頃からコミュニケーションにSlackを活用されていることかと思います。 …しかし、コミュニケーションというものはやはり難しいものです。 数多くのメンバーが所属していると、ときに問題が起きることがあります。 本日はSlackAdvent Calendar 2016 1日目を記念致しまして、 そういった問題の例示とその対処法を紹介します。 特定チャンネルの秩序と均衡を維持する #general のような特別なチャンネルを除き、 誰も出られないチャンネルというものを作成することはできません。 そのため、重要なチャンネルから勝手にleaveしたり等、 【反逆行為】に手を染める【レジスタンス】が発生することがあります
OAuthがソーシャルログインで使われるようになった経緯
最近の僕の趣味は、stack overflowに来た質問に回答を付ける、ということです。特に本家英語版の方では、英語の読み取りと作文の練習をかねてやってます。もちろん、日本語版の方でも、回答できそうな質問が来たら、積極的に回答するようにしています。たまに間違えた回答付けてしまって-1をもらうこともありますが、それを含めての貢献かな、と。気にしない気にしない。 さて、日本語版の方でOAuthに関する以下の質問が来ていました。 OAuthはどのようにしてソーシャルログインとして使用されるようになったのでしょうか？ 下記の記事をみるとOAuthはもともと外部からAPIを呼ぶためのものであり、ソーシャルログインとして使うのはHack的な使い方のような印象をうけました。 本来の目的が、ソーシャルログインのためでないならどのような経緯(どこどこのサービスで使われたのがきっかけというような歴史）でソーシ
OpenID Connectはそんなに大変かね？ - OAuth.jp
OAuth 2.0 + OpenID Connect のフルスクラッチ実装者が知見を語る – Qiita ってのになんかフォローアップしろよ的なのが来たので。 ざっと読んだ感想としては、「OpenID Connect の OPTIONAL な機能全部実装したら、そら大変ですね」という感じ。（Authlete に関しては、OpenAM みたいな感じで使われる、OpenAM よりはるかに簡単に使える代わりに有料の何かなんだろうな、というイメージです） OAuth は必要なのか？ Basic 認証は死んだ。 ユーザー単位での API のアクセスコントロールがしたいです。 っていう前提で話すると、OAuth 以外まともな選択肢が無いんじゃないでしょうか。 OAuth の各種 Extension (RFC 6749 & 6750 以外にいろいろある) に関しては、適宜必要なのを実装すればいいんだけど
よくわかる認証と認可 | DevelopersIO
よく訓練されたアップル信者、都元です。「認証 認可」でググると保育園の話が山程出て来ます。が、今日は保育園の話ではありません。そちらを期待した方はごめんなさい。こちらからお帰りください。 さて、先日のDevelopers.IO 2016において、マイクロWebアプリケーションというテーマでお話させて頂きました。一言で言うと OAuth 2.0 と OpenID Connect 1.0 のお話だったのですが、これらを理解するにあたっては「認証」と「認可」をはっきりと別のものとしてクッキリと認識する必要があります。 まず、ざっくりとした理解 認証と認可は密接に絡み合っている一方で全く別の概念です。正直、理解は簡単ではないと思います。 まず「認証」は英語では Authentication と言います。長いので略して AuthN と書いたりすることもあります。意味としては 通信の相手が誰（何）であ
OAuth for Native Apps | GREE Engineering
GREE Advent Calendar 9日目は @nov が担当します。 僕は GREE ではセキュリティ部に所属しており、社外では OAuth や OpenID Connect などの Identity 関連技術についての翻訳や講演などを行ったりもしています。 今日は GREE Advent Calendar ということで、Native App コンテキストでの OAuth の話を少し書いてみようと思います。 はじめに Native App を開発していると、Backend Server とのやりとりや Facebook Login や Google Sign-in などで、必ずと言っていいほど OAuth 2.0 というのが出てきます。 OAuth 1.0 と異なりリクエストに署名が不要だったり、Client Secret (a.k.a Consumer Secret) 無しでも
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つのサービスの間でリダ
Covert Redirect Vulnerability with OAuth 2
tl;dr Covert Redirect Vulnerability is a real, if not new, threat when combined with Implicit Grant Flow (not Code flow) This Covert Redirect Vulnerability in OAuth 2 is an interesting one. There’s a couple of defending arguments that this isn’t a flaw in OAuth itself. While I agree that it isn’t a flaw in the protocol, I think the threat is a real one, combined with a) a loose validation on redir
OAuthとOpenIDの問題ある実装が存在するという話：Convert Redirect - 発声練習
追記：こっち読むべき 「Covert Redirect」についての John Bradley 氏の解説 本文 OpenSSLのHeartbleedの話ほどは深刻ではないですよとのこと CNET：OAuthとOpenIDに深刻な脆弱性か--Facebookなど大手サイトに影響も Leandro Boffi: Covert Redirect: Facebook and ESPN Security, oh my god… Now, I have to say that it is not new, in fact really surprise me that this kind of attacks are still possible, and it is not an OAuth 2.0 / OpenId vulnerability, but it could be a problem o
Twitter連携アプリを利用するなら知っておきたい108のこと - CGMプランナーの思考
文責：ウェブ研プログラマー はじめに ここ数日で話題になっているTwitter連携アプリに「日頃の行いおみくじ」がありますが、「日頃の行いおみくじはスパムだ！」というツイートが拡散されまくって悲しい感じになっています。 ウェブ研でもTwitter連携アプリを作成していますし、あらぬ誤解をうけるアプリケーションが減ればいいな（ついでに宣伝もできればいいな）と思い、ユーザ向けに、OAuthを利用したコラボアプリのものすごくざっくりとした解説記事を書いてみました。 次のような構成になっています。 ・OAtuhのものすごくざっくりとした説明 ・Twitter連携アプリ固有の話 ・ユーザはどうしたらいいか ※随所にウェブ研の宣伝が散りばめられてます お、OAuth…？ Twitterアカウントでログイン、FacebookアカウントでログインといったことができるアプリケーションではOAuthという規約
自社サービスの機能を簡単にAPIで提供出来てしまう！gem doorkeeperが凄い。 - @camelmasaの開発日記
自社サービスにAPIを実装する事ってあまりないですよね。 kamadoのプロダクトも現在はAPIは公開してません。 もし提供するのであれば、簡易的な方法ですが、ユーザーテーブルにtokenカラムを追加して、API用のルーティングを作成する…という方法が考えられると思います。 しかし、その実装時間でより良いAPIが実装出来るとしたら素晴らしいですよね。 そこで紹介したいのがgem doorkeeperです。 日本語の記事が見当たらなかったので記事にしました。 github https://github.com/applicake/doorkeeper gem doorkeeperってどんな機能があるのか？ 簡単に説明すると、 ・アプリケーションの管理機能 ・アプリケーションの承認管理 ・スコープの設定 いってしまえば、Facebook API(に近い実装)そのまま実装出来ます。 しかもOAu
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TechCrunch | Startup and Technology News