Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? TL;DR HTTP でトークンを利用した認証・認可をする手法として RFC 6750 がある OAuth に限らず、トークンを利用して認証・認可する機構の一部として Authorization: Bearer ヘッダを使うことができる 使い方について詳しくはこの記事の下のほうに書いた 要求 トークンを利用した認証・認可機構を持つ API を作りたい クライアントがトークンを HTTP リクエストに含めて送信し、サーバはトークンを検証してリソースへのアクセスを許可したい Authorization: Bearer トークン ヘッダでトー
Internet Engineering Task Force (IETF) B. Laurie Request for Comments: 6962 A. Langley Category: Experimental E. Kasper ISSN: 2070-1721 Google June 2013 Certificate Transparency Abstract This document describes an experimental protocol for publicly logging the existence of Transport Layer Security (TLS) certificates as they are issued or observed, in a manner that allows anyone to audit certificat
その1 / その2 / その3 Declined RFC 最近のPHPでは、新機能はまずML等にアイデアを出してRFCを作成し、投票において有権者の2/3の賛同を得て初めて導入されるという流れになっています。 その関門を通り抜けたものだけが新機能としてデビューできるわけですが、中には当然却下されたものも存在します。 せっかくだから却下されたRFCを、新しい順に10件見てみます(2016/08/09時点)。 今後通りやすいRFCを提案する際の参考になるかもしれません。 その2に続くかどうかは不明。 New operator for context-dependent escaping 賛成0/反対27で却下。 が等しくなるという提案。 おいやめろ馬鹿と言わざるをえないRFCですが、さすがに皆そう思ったようで、圧倒的支持率で却下されました。 さらにset_escape_handler()で任意
メールアドレスの「ルール」に関する話題が盛り上がっていますね。 「メールアドレスのルール」系まとめがそろって間違ってるのでご注意を 「メールアドレスのルール」なんて使ってはいけない3つの理由 これらのエントリに異論があるわけでありません。メールアドレスに関するルールというとRFC5322などがあるものの、現実の運用では簡易的な仕様を用いている場合が大半である…という事情は、私も以前ブログに書きました。、 本稿では、「空前のメールアドレスのルールブーム(?)」に便乗する形で、RFC5322に準拠したメールアドレスで、XSSやSQLインジェクションの攻撃ができることを紹介します。と言っても、SQLインジェクションについては、過去に書きましたので、本稿では、RFC5322バリッドなメールアドレスでSQLインジェクションとXSSの両方ができるメールアドレスを紹介します。 まず、攻撃対象として、以下
11月10日付けでGoogle Public DNSに関する計測記事(参考)が、ヨーロッパ・中東・中央アジア地域の地域レジストリ(RIR/Regional Internet Registry)であるRIPE NCCで公表されましたが、その次の日付でフランスのAFNICに所属する著者によってDNSにおけるプライバシ問題をまとめたInternet Draftが公開されました。 DNS privacy problem statement このドラフトを書いているのは、DNSデータをJSON形式でやり取りするドラフト(draft-bortzmeyer-dns-json)を提案していた人ですね。 まだ、個人ドラフトですし、バージョンも00の段階なのですが、Acknowledgmentsを見ると業界な方々のお名前が記載されているようなので、もしかしたらwg draftになるかも知れないと思えましたが、
RFCとなった「OAuth 2.0」――その要点は？：デジタル・アイデンティティ技術最新動向（2）（1/2 ページ） いまWebの世界では、さまざまなWebサービスが提供するプラットフォームと、サー ドパーティが提供するアプリケーションがAPIを中心に結び付き、一種の「APIエコノミー」を形成しています。この連載では、そこで重要な役割を果たす「デジタル・アイデンティティ」について理解を深めていきます。 再び、デジタル・アイデンティティの世界へようこそ 前回「『OAuth』の基本動作を知る」ではOAuthの仕様がどういうものかについて説明しました。今回は引き続き、 OAuth 1.0とOAuth 2.0の違い OAuth 2.0をセキュアに使うために知っておくべきこと について述べていきます。 OAuth 1.0とOAuth 2.0の違い クライアントタイプの定義 OAuth 2.0では、O
IPA/ISEC（独立行政法人 情報処理推進機構 セキュリティセンター）は、インターネットセキュリティに関する重要な RFC（Request for Comments）を日本語に翻訳して提供しています。 RFC は、IETF (Internet Engineering Task Force) におけるインターネットコミュニティの標準等の検討が公表される一連の文書であり、1969年に発行され始めました。それらの内容としては、インターネット標準の仕様のみならず、現時点における最善の実践（BCP）、FYI（For Your Information）を含む情報提供、実験的なもの、および、歴史的なものがあり、広範にわたります。原文は、英語で記述されています。 この目的は、 「ベンダーによるインターネットセキュリティ機能の実装を促進すること」および「ユーザのインターネットセキュリティについての認識を向
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く