分散キューという名の苦しみ - Software Transactional Memo
TL;DR 分散システムにおいてキューを導入する場合、本当にキューが必要なのか再考すべき。そこが地獄の入り口だから。 システムの抽象 コンピュータの世界は、本来は0と1の信号の羅列が飛び交う無機質なものである。でも人類は信号だけですべてを語らず、様々な喩えを定義してきた。それはデスクトップ・ウィンドウ・マウスカーソルといったグラフィカルな表現に留まらず、パケットやカプセル化といった用語にロック・キュー・リスト・木などのアルゴリズムやデータ構造の世界にも自然に溶け込んでいる。これらはすべて人間の理解を助けるための喩え話に過ぎず、この喩えこそが人間のより直感的な理解をもたらす一方で、発想の制約を生み出してきた。 人間が大きなシステムを作るときも何らかの喩えを用いてシステム全体を整理する。アーキテクチャの「ポンチ絵」を描いて情報共有をするのは企業に勤めていれば経験した人も多いだろう。パワーポイン
【Rails5】Doorkeeper gemでOAuth2.0のためのAPIを作って、rubyクライアントで呼び出す - daily-dev.net
DooerkeeperはOAuth 2のプロバイダ（認証する側のサーバー）を簡単に実装できるgemです。 意外とハマったので書いておきます！ Doorkeeper gemをインストール github.com #Gemfile gem 'doorkeeper' gem 'doorkeeper-i18n' # default localeを en 以外で使うなら #terminal rails generate doorkeeper:install rails generate doorkeeper:migration #active record 使うなら rake db:migrate routes.rb Rails.application.routes.draw do use_doorkeeper #追加 end ↑で以下のルートが生成されます. GET /oauth/authorize
RFC7662: OAuth 2.0 Token Introspectionでアクセストークンの検証を行う - Qiita
はじめに API認証にOAuth2を使う場合、認可サーバでアクセストークンを発行して、リソースサーバ(APIサーバ)にアクセストークン付きでリソースをリクエストするわけですが、認可サーバとリソースサーバが分かれてる場合、アクセストークンをリソースサーバで受け取ったあとに、このトークンは正しいのか？どのようなスコープが許可されているのか？どうやって確認すればよいんだろうかという疑問が湧いてきます。 OAuth2そのものの「RFC6749: The OAuth 2.0 Authorization Framework」では仕様の範囲外として記載されていませんが、調べたところ、OAuth2の拡張仕様で、以下の選択肢があるようです。 RFC7662: OAuth 2.0 Token Introspection RFC7662は認可サーバのトークン確認用エンドポイントにリクエストを送信し、レスポンスと
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
