  |
はてなキーワード: Jsonとは
Excelを持っているならはてブのJSONデータをそのまま取り込めるそうだからそのデータを使ってブクマが付いた時間のグラフが描けそう。
例えばこんな感じでJSONデータが取れる。 http://b.hatena.ne.jp/entry/jsonlite/https://anond.hatelabo.jp/20180315232737
Excel持ってないならスクリプトでCSVにしてしまえばいい。
rubyスクリプトだとこんな感じ。(Mechanize無し版に差し替え。なぜMechanizeを使っていたかと言うとはてブがUser-Agentが空だと値を返してくれないから。ちょっと長くなるが自前でUAを渡すようにした。)
#!/usr/bin/ruby
site = ARGV[0]
json_uri = URI.parse("http://b.hatena.ne.jp/entry/jsonlite/%s" % [site])
response = Net::HTTP.start(json_uri.host, json_uri.port) do |http|
http.get(json_uri.path, "User-Agent" => "Mozilla/5.0")
end
json_data = JSON.parse(response.body)
json_data['bookmarks'].each do |bookmark|
puts [bookmark['user'], bookmark['timestamp'], bookmark['comment'], bookmark['tags'].to_s].to_csv
end
引数に取得したいページのURLを入れる。hatebuapi-csv.rbという名前で保存したとしたらこんな感じで実行。
% hatebuapi-csv.rb https://anond.hatelabo.jp/20180315######## ＞ 結果.csv
大企業がクライアントの案件を受注したらしく社内説明会でどんなものを作るのか聞いてきた
詳しいことはもちろん書けないんだが、大雑把にいえば、その社内でのやることに応じたシステムが１０や２０とある
それぞれ独自のフォーマットのデータを扱うからシステム間のフォーマットを変換するシステムが必要のようでそれを作るらしい
こういうのは大きいところならよくある話だとか
そして今回作るようなシステム間のデータの相互変換のようなシステムはすでにクライアント社内にいくつもあるらしい
さらにはそれら変換するシステム同士をつなぐシステムというものもあるらしい
それぞれのフォーマットは別だが中身はおなじということが多いらしい
それってなんか無駄すぎない？
フォーマットをXMLとかJSONとかTSVとかの汎用フォーマットで統一して各システムが必要な部分だけをみればいいんじゃないの？
お金もらえるわけだから無駄であろうと作るのだろうが、無駄なものがどんどん膨らんで行きそうな気がして仕方がない
なんかシステム作る側があとから変換システムも作ってお金もらうために独自フォーマットを採用しているように思えてくる
日本の IT がダメとか言われるのも価値のある新しいものを作るのじゃなくてこんな無意味なものをいっぱい作ってるからなんじゃないかなーとも思った
クライアント側が過去のものをそのまま使いたいとか変な要望を無理に通したせいでこんなことになってきたということもあるのだろう
私がいるところは、プログラマ/システムエンジニア、フロントエンドエンジニア/バックエンドエンジニアとかの区分がなくひとりでなんでもやるところです
一応フロントエンドが好きで得意だと自称はしているものの一般的なフロントエンドってどこまでするのでしょうか
デザイナがするような部分
ここは当然でしょう
最近では SPA のページも多いので単純な HTML と JS ではなくフレームワークを必要とされることもあります
SEOの都合などでJSレンダリングじゃなくサーバサイドレンダリングで、サーバから受け取るHTMLの時点で表示できる状態になってることを依頼される場合もあります
その場合はサーバサイド言語に応じたテンプレートエンジンも使います
PHP なら Blade、Python なら jinja、 Node.js なら ejs という感じ
JS のコードをテストしたり gulp などのタスクランナーや webpack などバンドルツールを使うので OS のコマンドラインのツールも使える必要があると思います
サーバサイドの言語は別の人が作るにしても自分の環境でそれを動かすためにサーバ構築は出来たほうがいいでしょう
VM に OS のインストールしてウェブサーバをインストールしたり
Vagrant, Ansible 等で管理されているなら、設定ファイルを書くことはないにしろ実行する方法やエラーが起きたときの簡単な対象方法くらいは知っていないと不便かと思います
ウチの場合は各自LinuxをVMにインストールして Ansible でという使い方なので気づきませんでしたが、考えてみたら全部設定済みの VM データを配布してくれるということもあるのかもしれません
データによって画面表示を変えるときに、それに応じたデータを作って画面を確認したいことがあるので、mysql や postgres などなどデータベースの知識も必要になることがあります
SQL 書けなくても pgadmin みたいな GUI ツールで表を書き換えればいいのですが最低限の仕組みは知っていないと苦労しそうです
完全にフロント/バックが切り離されてるところなら、フロントエンド開発者向けにデータベースは使わずテンプレートエンジンに渡ってくるデータを好きに設定できる機能が用意されてるのかも？とも思います
サーバサイドの処理は不要でクライアントサイドの動きのみを作るわけですから、決まった場所の JSON ファイルのデータがそのまま使われるならデータベースの存在を知らなくてもいいですし
ここまでできたらバックエンドよりフロントエンドのほうが何でも出来る人みたいに思えます
あとはサーバサイド言語を書ければもうサービスが作れてしまいます
でもこれぐらいできないとすごく不便で、すぐに他の人に頼らないといけなくなるように思います
サーバ冗長化とかそういった部分はかかわらなくてもいいと思いますけど、Linux やデータベースなんかは自分でどうにかできないと周り誰もいないときに動かなくなったら作業進められななんてことがありそうですし
もう一つの方法としては、javascript版だ。
https://gist.github.com/bellbind/d9dc9ccdd4a8735a9990
２倍固定だけど。
デモページで試してみたら、javascriptがicabやらsafariでは動かない。
かろうじてFifefoxやchromeで動く。
最初ダウンロードして、OSXのweb共有で試してみようと思った。
→動かない。単純拡大の方はスパッと表示されるが、その下の表示が "Progress: initialize worker..." のままで停止。
Apacheの設定を変えるといいのかもしれないが、あくまで仕事の機械だしね。
結論としてはダウンロードしたHTML書類を、Finderから右クリックしてFifefoxで開くとなぜか動くというのが確認できた。
へーってなった。
（ちなみにHTMLをエディタで開いてjsonをgithubのURLにしたらweb共有からでも動くのは確認した。
ただし外部サイト側に迷惑をかけないためという主旨なんで元に戻している。それでいいなら公式にブラウザでアクセスするので
プログラマなんだけど、なんでも揃えようとしてる人がうざい
よくあるのが、JSON とかオブジェクト系の記述するところで、 「:」とか「＝＞」みたいなのの位置
揃えられると一見すると見やすいが、金額みたいに揃ったみやすさが必要ないところでされると面倒
10行並んでたら1つ変えたのが原因で10行とも変えないといけなかったりする
面倒だけどツール使えば揃えること自体は楽にできるからこれはまぁいい
だが、バージョン管理ソフトでの変更行数が無駄に増えるのでパット見たときに結構大きな変更してるように見えたりするからちょっとイヤ
さらに grep かけようにも空白数が不定だから正規表現にしないといけない
んだけど、まあここまでは別にいい
この揃えるときに
aaa : { bbbb : 100 ccccc: 200 }, dddd : { e: : 300 }
みたいに（フォントによっては揃ってなく見えるかも）、ネストが違うのに全部を揃えようとするの、ホントやめろ
わかりづらい
上の例みたいなシンプルだと困らないが複雑な構造になってるとかなり見づらい
上でいう aaa と dddd の行が10行程度離れていたら、ここを揃えても全くきれいに見えないし無駄
bbbb と ccccc みたいなときだけならまあ許せる
仏の顔も三度まで、
(1) 文字数を合わせようとする
上で書いたみたいなのは文字数が違うから合わせるためにスペースを入れる必要がでる
きれいなのはわかる、だが無理やり合わせようと単語を探し始めるとかありえない
5つ項目があって、4つが6文字の単語で残りの1つが4文字だったとする
無駄な上に、本来のそれに適した単語じゃないのを無理やり使うのでわかりづらい
揃ってることはパット見綺麗でもプログラムみたいのだと、単語まで似てると気づかないミスが出て来る
beer と bear、 form と from、 fall と fail みたいな見た目が似てる単語と、見た目が全く違う単語の比較ではミスの数が明らかに変わると思う
なのに、 enum みたいな選ぶタイプのもので、数文字違うだけの似た見た目の単語を探してきて選ぶとか、ミスを誘発しようとしてるのかと言いたい
(2) 単語の語尾とか
(1)のように大半が揃ってると残りも無理やりそうしたいということで、単語を勝手に変化させたものがある
例えばだが、語尾が1つを除き全部 -ly になってたとする
そうすると残り一つに無理やり ly をつける
なんなの？イン踏みたいの？ラッパーなの？？
そもそも名前みたいな固有名詞にすらそんなことしてるから意味不明にもほどがある
上の時点で英語を完全無視で英語力のなさはわかっただろうが、さらにこういうのもある
過去形には ed 、複数形には s のようなルールには単語によっては特殊な形をするものがあるのはもちろん知ってると思う
プレフィックスに is つけるみたいな単語の組み合わせ部分なら気にしないけど単語としておかしいから、自分で書くときに本来の形で書くとエラーでるからさらにイライラする
例えばこういうこと
readed, catched, taked, companys, boxs, mans, childs, fishs, classs
見てるとムズムズする
英語得意でない自分ですら違和感を感じるのに、これに何も感じないとか英語力ひどすぎると思う
まあエラーメッセージで don't have ～ とすべきところを has not ～ とか書いてたくらいだからなぁ
これが部下とか下の立場の人なら 「使う前にググってみて。おかしかったら『もしかして、～～』みたいの出るから」と言って直させるけど、上だからどうしようもない
間違ってますよー、と遠回しに言ってみたことはあるものの、直す気は全くないようだし、それどころか無邪気に揃えてやったぜみたいなこと言ってドヤ顔してるからホントどうしようもない
https://www.nasnem.xyz/entry/incorrect-comprehension-test
http://mubou.seesaa.net/article/453754579.html
どっちもとんちんかんなことを言っているので、この問題について解説。
1「輸出が伸び悩む中でも、和牛が人気の牛肉や、和食ブームを反映した緑茶や日本酒などは好調だ。」
2「輸出が伸び悩む中でも、和食ブームを反映した日本酒や緑茶、和牛が人気の牛肉などは好調だ。」
1と2を同じ意味に解釈することはできますか。と問われればイエスだが、全く同じですか。と問われればノーだ。
同じ意味に解釈したときの文章構造をJSON風に表記するとこうなる
輸出が伸び悩む中でも好調だ : [ { 和牛が人気の : ["牛肉"] }, { 和食ブームを反映した : ["緑茶","日本酒"] }, "など", "など", "など", //以下任意のなどが続く。"など"の中身はなんでも良い ]
輸出が伸び悩む中でも好調だ : [ { 和牛が人気の : ["牛肉"] }, { 和食ブームを反映した : ["緑茶","日本酒","など","など","など",] //以下和食ブームを反映した"など"が続く }, ]
2の文と同じ意味の文はどれですか、と問われれば1を選ぶが、
ジェイソンは、階層構造が持てるので、表形式やCSVより複雑なデータ構造を定義しやすい特徴があると思います。
この話は、途中で「危ない」の意味がすり替わっているので混乱してるんじゃないかな？
これが許可された場合に攻撃の危険性にさらされるのは「リクエストを受ける側」のサーバだ。
この場合、攻撃者である可能性を持つ「リクエストを投げる側」は不特定多数である。
2. ＜script src=""＞なら他ドメインも取れるよ ← まあわかる
3. じゃあここを動的に変えて、実体はスクリプトファイル(JSONP)で関数呼んでデータ貰おう ←！？
関数実行しちゃってんだぜ？
これが許可された場合に攻撃の危険性にさらされるのは「リクエストを投げる側」であり、先ほどとは攻撃者と被攻撃者が逆転している。
この場合、攻撃者である可能性を持つ「リクエストを受ける側」は、「リクエストを投げる側」が明示的に指定したサーバだ。
この問題は信用できないドメインに対して自分側からリクエストを送らないようにする、という明確な対策が可能である。
JSONPは、「リクエストを受ける側」にとってXMLHttpRequestでWebAPIを叩かれるよりも安全だからドメインを超えた通信が出来るわけ。
つまりこういうことね。
【XMLHttpRequestの危険性 (実際にはこの動作は禁止されている)】 ブラウザ←ーーー「攻撃者WEBサーバ」（悪意あるリクエストを投げるコードをブラウザに渡す） ーーー→「被攻撃者WEBサーバ」 (悪意あるリクエストに答えてしまう) 【JSONPの危険性】 ブラウザ←ーーー「WEBサーバ」（攻撃者WEBサーバへリクエストを投げるコードをブラウザに渡す。※このサーバは、攻撃者WEBサーバに悪意があることを知らない) ーーー→「攻撃者WEBサーバ」（レスポンスとして悪意あるコードをブラウザに渡す） ブラウザ←ーーー (悪意あるコードを実行してしまう)
前エントリー: http://anond.hatelabo.jp/20170216041052
遊びでJSONでブックマークデータを取れるようにしたので2日後のデータを。
7,604個の公開されたIDが11,986回のブックマークを行い、3,714回の非公開ブックマークと合わせて15,700回のブックマークにより11個の1000ブクマ超え記事を生み出していた。
前回より高頻度重複IDが減っているのは[あとで読む]タグブクマが消化されたのか、手作業で数えた私が間違えていたのか、スパマーにそういう習性があるのか、ちょっとわからない。
前エントリーでチェックした1000ブックマーク以上されている11記事中n記事にブックマークしているID数
8, 15 ID
6, 52 ID
5, 99 ID
2, 1481 ID
重複なし, 5126 ID
(注: n重複のID数の中にn+1重複のID数は含まれていない。つまり10重複のID数の中に11重複のID数は含まれていない。)
| 全ブクマ数 | 公開 | 非公開 | url |
| 2594 | 1860 | 734(28%) | ttp://www.nakahara-lab.net/blog/archive/7308 |
| 1972 | 1485 | 487(25%) | ttps://togetter.com/li/1079883 |
| 1733 | 1367 | 366(21%) | ttp://omocoro.jp/kiji/101534/ |
| 1385 | 1019 | 366(26%) | ttp://qiita.com/shu223/items/9e3a50e092c2997fe6d2 |
| 1275 | 1026 | 249(20%) | ttp://ironna.jp/article/5686 |
| 1231 | 999 | 232(19%) | ttp://blog.tinect.jp/?p=36441 |
| 1163 | 915 | 248(21%) | ttps://togetter.com/li/1078513 |
| 1135 | 790 | 345(30%) | ttp://www.lifehacker.jp/2017/02/170205_free_alternatives.html |
| 1130 | 839 | 291(26%) | ttp://careersupli.jp/lifehack/eiga/ |
| 1053 | 827 | 226(21%) | ttp://anond.hatelabo.jp/20170206102543 |
| 1029 | 859 | 170(17%) | ttp://appmarketinglabo.net/staba-sns/ |
http://vim-jp.org/vimdoc-ja/change.html#filter
Vimにはフィルタコマンドといって、テキストを任意のUNIXコマンドで処理するExコマンドが用意されている。
用意されていて、実際強力なんだけど、Vim組み込みの機能で間に合うことも多くて、下記以外はあまり使っていない気がする。
以前はVimの正規表現に慣れないからとPerlを使ってたりもしたけれど、Vimの正規表現も悪くないかなとなって。こう。
簡単な計算をするときに使う。1行に計算式を書いて「:.!bc<CR>」あるいは「!!bc<CR>」とすると計算ができる。
「<C-r>=」で代用できる。
長めのコマンドを実行するときに使う。「:%!sh<CR>」とすると書いたシェルスクリプトを実行できる。
最近はBashの<C-x><C-e>で良い気がしてる。こちらだとヒストリで戻って<C-x><C-e>として再編集することもできるので。
簡単な整列をするのに使う。ビジュアルモードで選択して「!column -t<CR>」とすると整列ができる。
(デフォルトのセパレータがスペース二つなので、一つにしたければ-oオプションを指定して「!column -to' '<CR>」という風にする)
vim-easy-alignやvim-aligntaが入っているならそれでいいかも。
それぞれJSON、XML、HTMLを整形するのに使う。JSONは「:%!jq .<CR>」、XMLは「:%!xmllint --format -<CR>」、HTMLは「:%!pup<CR>」。
ただ「jq . <JSONのファイル> | vim -」としていたりして、直接Vimの中で使ってない場合が多いかも。
連番を振る時、重複行を削除する時、指定した列を抜き出す時、などなど、色々なことに使える。
それぞれ「:%!awk '{printf"\%-6d \%s\n",NR,$0}'<CR>」、「:%!awk '\!a[$0]++'<CR>」、「:%!awk '{print$2}'<CR>」といった風にする。
保存するために管理者権限が必要な場合にsudoと一緒に使う。「:%!sudo tee %<CR>」とすると保存できる。
anond:20160426124418 と anond:20160426145507 の続きだゾ。てか長えよ
(略: トークンが定期的に期限切れになるので可用性が下がる。たとえばビデオカメラから複数の動画をアップロードしている途中で切れたらムキーってなる。再認証して途中からできるのもそれはそれで CSRF の温床。AFCP のような場合は期限切れがあってはならないので、パスワード等を預かる認証プロキシの SaaS アプリを筆者は作った。好評だったが、これはもちろん本来あるべきでない欠陥のexploitのはず。)
(略: 個人ユーザ向けのAPI設計ばかりで、雇用者や上司がアカウントを管理するという観点がない。SAMLでは普通にできるのに、OAuthとなるとセキュリティ的に云々と言って拒むサービスばかり。別のUIで既にできてることをAPIにしても意味がない。これまでできなかったことをAPIで可能にするのではなく、単なるシングルサインオンでよければ他にある。実際Googleは個人向けにはOAuthを活用しているが、Google Apps for BusinessはOAuth以外のシステムを使っている。)
(略: 主要な設計ミスは、外部サービスすべてを同等に疑うところ。管理者が各サービスの信用性を判断して権限を調節できるようにしないところ。これまでどれほど多くの製品がOAuthの面倒さのために失敗してきたことか。)
ここまでで「普通の実装における」OAuth がまったくおかしいということはわかりましたが、OAuth が実際うまくいくのはどういうときでしょうか。
初期の OAuth 規格および概念におおよそ付き従っているシステムは一般的に言って、新しい規格ベースのよりもセキュアで、マシです。OAuth 1.0 の実装がすべてセキュアだというのではありませんが、たいてい問題は少ないです。こうしたシステムは通常、次のふたつのアプローチのどちらかに従っています:
とはいえ、このように設計されている OAuth ベースのシステムはごくごく希少で、しかも一般的にこうしたシステムは、他のところで使われている OAuth とは似ても似つかぬものです。OAuth 1.0 規格の方に寄って頑張っていますが、公式には 1.0 は非推奨ですから、こうしたアプローチを使っているシステムはそのうち「アップデート」されて OAuth 2.0 の概念や追加機能すべてを加えて再構築され、セキュリティやユーザビリティをだめにしてしまうことになります。これこそ筆者があらゆる OAuth ベースのものを見逃したくない理由です。もっと古く、もっと機能的な形式の OAuth を使っていても、システムに「改善」が必要だという素敵な考えを管理者のだれかが閃いて台無しにしてしまうからです。ご迷惑をおかけしてすみませんと言うぐらいなら、まったく別のものを使うほうが良いですよね。
他に手はないかと探すとき、人々はよく他の「フレームワーク」にはどんなものがあるかを知ろうとします。しかし、考え抜かれたセキュアな設計を実現するためには必ずしもフレームワークが必要というわけではありません。現状、OAuth とはどのようなものかについての意見はサービスごとに異なっていますので、承認の具体的な動作の仕組みもまったく一定ではありません。そんな中でフレームワークを探しまわるのは、簡単にできることをいたずらに複雑化しているだけのことが多いです。唯一ほんとうに難しい要素、しっかりした規格の必要な要素は、使用する鍵パラメータの改竄を防ぐため変数に署名する方法だけであり、この点に関して、ほとんどの OAuth ベースの実装は一切何もしてくれません。
ウェブサービスの最大手である Amazon は、世界中の企業にサービスを提供する一流プロバイダで、合計 30% 以上という途方もない市場シェアは他者を圧倒しています。Amazon のアプローチは、自分でアプリの認証情報を生成できるコントロールパネルへのアクセスを、すべてのアカウントおよびアカウント管理者に提供することです。この認証情報で、どの Amazon サービスで作業できるか、そのサービスでどの操作を実行できるか、どの権限で作業しなければいけないかを指定できます。この認証情報は必要に応じて「アカウントホルダ」の人が破棄することもできます。
Amazon の API における認証や承認技術には、本質的に制限が多く潜在的に危険性のあるリダイレクトを一切必要としません。Amazon のプロトコルで認証情報は、直接送ることは一切なく、データの署名に使うのであって、これでブラウザを通してパラメータを送る必要のあるときにも改竄不可能にすることができるのです。
Amazon の設計はアカウントの利用状況を API の利用まで適切に把握できますし、API の認証も承認もすべて Amazon 側からスタートし、その際のアプリ認証情報も「Amazon の」コントロールパネルから生成されます。この認証情報はその後、いかなるトークン交換システムも使わず直接 API プロセスで使われます。この設計なら「普通の実装における」OAuth が達成している真のセキュリティ目標をすべて達成し、かつ前述したセキュリティ上およびユーザビリティ上の問題をすべて回避しています。
ひとつ言及せざるをえない短所は、Amazon の権限システムが幾分わかりにくく、あまりユーザに優しくないということです。ただし、このことは何故かほとんどのコントロールパネルにも言えることで、いずれにせよ UI 設計の問題であって、承認プロセス自体の失点ではありません。さらに、Amazon のコントロールパネルはかなりキビキビ使えて、それ自体の API でも使えます。この点たとえば Google の場合のように、筆者の知る限りメタ API もなく、何をするにも何十もの手順が必要なのとは大違いです。
Amazon の認証および承認メソッドは他のサービスプロバイダにも幾つかコピーされています。Google 自身も企業向け製品の一部でこれを利用できるようにしています。Google 自身、純粋な OAuth 設計は企業サービスに向いていないことを認めており、企業サービスには JSON Web Tokens (JWT) の利用を推奨しています。
JWT はサービス間の SSO や API 利用を可能にする規格です。多くの点で JWT は SAML に似ていますが、SAML はややこしくて、XML Security (名前と違って、まったくセキュアではない) の上に構築され、API 利用に向いていないのに比べ、JWT は SAML の主要な目標を、単純かつ使いやすい方法で一切の面倒なく達成しています。HMAC 実装をひとつ用意し、JSON の構築と解析の方法を知っておけば JWT は使えます。既製品をお求めでしたら、膨大な JWT ライブラリが既に存在していますよ。
ただ Google の場合、典型的な JWT 利用法よりも高度で、HMAC のかわりに、もっと高度ですがこの分野では人気の低い RSA デジタル署名を利用するよう要求しています。Google のコントロールパネルではアカウント管理者が自分の企業サービス用に新しい鍵ペアを生成でき、API ログインを署名するために使う秘密鍵をダウンロードできます。こちらのほうが HMAC よりセキュリティは高いですが、Google はプロセス全体を本当に無駄に複雑化しています。コントロールパネルをしょっちゅう完全に再設計して、前と同じことをしたいのに使い方が違っていて混乱する点は言うまでもありません。JWT 利用の実例が必要なら他をあたるようお勧めします。
他に使われている技術は、サードパーティがどんな権限を必要としているかをある種の XML や JSON ファイルで定義してウェブサイトに送信できるようにするサービスのものです。ユーザがあるページを自分のアカウントで訪問し、ファイルの URL (あるいは中身) をそこに貼り付けると、その外部サービスあるいはアプリが求めている権限の一覧やそこに含まれる説明などが表示されるようになっています。それを見て認可したいと思うユーザは、認証情報を生成してそのサードパーティのアプリあるいはサービスに貼り付けます。ユーザは後で無効にしたくなったら認証情報を破棄することができます。これも、開発者におかしな負担を強いることなく、すべてのアカウントに API サービスがあり、権限管理を備え、サービス自体からフローが始まる、実にセキュアな設計です。
承認管理のためにサービス側から提供してもらう必要が本当にあるのは、適切な役職 (管理者やアカウント所有者など) を持つユーザが自分に割り当てられた権限や (望むなら) 期限を持つ認証情報を API 利用のために生成できる何らかのパネルだけです。こうした認証情報はその後、お好みのセキュアな認証システムを通して利用することができます。たとえば HTTP Basic Authentication over HTTPS のような単純なもの、これは事実上どの HTTP ライブラリにも入っていますし、HTTP Digest Authentication、これはもっとセキュアでありながらほとんどの良質なライブラリでサポートされていますし、その他 HMAC, RSA, 楕円関数など認証情報をネットに通す必要のない暗号学的テクノロジーを活用した認証プログラムに基づくものなら何でも使えます。特に HMAC は、承認や認証を実装するほとんどすべての人 (Amazon や、一部の OAuth 実装も含む) によって既に使われています。
こういった種々の実績あるテクニックは、セキュアなプラットフォームを作るために CSRF 対策など複数のフレームワーク同士の相性を勉強する必要があるという重荷を軽くしてくれますし、一般的に、既存アーキテクチャにワンタッチで装着できるようなモジュール化の実装が可能です。ユーザやアプリの認証情報が盗まれる可能性をなくしてくれます。ややこしい CSPRNG を常に使用する必要もありません。このようなシステムは OAuth の生まれるずっと前から存在しており、現在でも一般的です。OAuth は、ユーザの認証情報を要求したり他に弱点があったりするような一部の劣悪な設計のシステムよりはセキュリティが良いかもしれませんが、既にある真の設計を置き換えるものではありません。OAuth が解決すると主張する問題点は実のところ、既存の良く設計されたシステムには存在していませんし、「普通の実装における」OAuth は実のところ、解決すると主張する問題の多くを招き入れるばかりか、最初は存在していなかった問題まで生じさせています。宣伝文句と違って、OAuth にすれば自然と驚くほどセキュアになるというわけではなく、むしろ数々の短所や実装の困難さを考えれば、他の考え抜かれた選択肢のほうがはるかに優れています。
これからサービス設計をして API アクセスを提供することになっている方はどうか、ご自分が実現しようとなさっているのが何なのかを本当に考えてください。他の人がやっていることをコピーするだけで済ませたり宣伝を丸呑みしたりしないでください。どうしてもコピーしなければいけないなら、Amazon (これが最善です) や Rackspace, IBM SoftLayer, Linode, VULTR, Zoho, Zoom ほか、API の素直で健全な認証システムを構築する方法について現時点で多少なりとも理解のあるところをコピーするようにしてください。
2016 年 4月 Insane Coder
