Google OAuth2 Web Server Profileでのリフレッシュトークン
久々にGoogleのOAuth 2.0のWeb Server Profileを使っていて、あれ？って思ったので、ここでメモ代わりに書いておきます。 基本的には、以下のブログエントリで語られている話です。 Upcoming changes to OAuth 2.0 endpoint - The official Google Code blog OAuth 2.0でのWeb Server Profileのセオリーでは、以下の手順が踏まれます。 Client IDとScopeを指定して認可画面を要求します。 ユーザは認可画面を見て、許可するか拒否するか選択します。 redirect_uriにリダイレクトされ、その際にauthorization_codeが渡されます。 authorization_codeと引き替えに、access_tokenとrefresh_tokenを取得します。 acces
認証認可手順（新方式） - mixi Connect
各種APIをクライアントプログラムから利用するためには、OAuth 2.0 Protocolにより規定された認可を行うことが求められます。この手順により、クライアントプログラムがどのようなAPIアクセスを行い、そしてどのような情報が参照または更新されるのか（これをスコープと呼びます）がユーザに提示されます。ユーザの認証、および提示されたスコープについてユーザが同意した場合にのみ、クライアントプログラムはAPIにアクセスするための情報（トークンなど）を得ることができます。 [RFC 6749 - The OAuth 2.0 Authorization Framework] http://tools.ietf.org/html/rfc6749 [RFC 6750 - The OAuth 2.0 Authorization Framework: Bearer Token Usage] http:
xargs を使ってカジュアルに並列処理 - たごもりすメモ
シェルからでも重い処理というのはちょこちょこあって、例えば超デカいログファイルを移動して圧縮したりというお仕事は世界中のあらゆる場所で毎日行われていたりする。コマンドラインからでも大量の圧縮済みログファイルをいっぺんに展開したい、とか。 あるディレクトリ以下に存在するたくさんのファイルを(圧縮済みのものを除いて)全部 bzip2 圧縮したい！と思ったら、とりあえずさくっと次のようにコマンドラインで叩けばいい。 $ find . -not -name '*.bz2' | xargs bzip2 これで、まあそんなに問題なく効率的にbzip2圧縮ができる。だがしかし。 最近は複数コアのCPUが普通に転がってるし、あまつさえHyperThreadingが有効になってたりしてOSから見える論理CPU数がハンパない。普通に8とかある。その一方で複数コアを使用してくれるコマンドというのはあんまりなくて
NISTが警告、SMSでの二段階認証が危険な理由
印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます 「SMSでシークレットコードを送信するのはやめてください。安全ではありません」――。これは、米国立標準技術研究所（NIST）が2016年の夏前に発信したメッセージの内容ですが、この件についてさまざまな意見や疑問、戸惑いの声があがりました。この件に関する問題を整理してみたいと思います。 まず、事の経緯についてですが、NISTは「Digital Authentication Guideline」（デジタル認証ガイドライン）の草案を公開し、一般からの意見を募集しました。このガイドラインの最終版は2017年9月に発行の予定です。 ガイドラインの「Section 5.1.3.2」では「Out-of-Band verifiers」（帯域外検証者）に
Server::Starterから学ぶhot deployの仕組み - $shibayu36->blog;
以前http://tech.naver.jp/blog/?p=1369の記事を読んだのだけれど、それまでにprocessの知識が無かったりして、まったく理解できませんでした。そこでWorking with UNIX ProcessesやServer::Starterの中身を呼んでようやくhot deployの仕組みを理解できた(気になっている)ので、Server::Starterの実装を追いながら、それをまとめてみます。 hot deployとは hot deployとは「再起動の時にリクエストの処理を続けながら、変更の内容を反映するための手段」です。 通常serverをrestartさせるときは、stop -> startの流れになると思いますが、この場合stopしてから、start出来るまでの期間にリクエストを処理できない期間が発生します。その期間なしにdeployする仕組みがhot
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
[JavaSpecialists 136] - Sneaking in JDBC Drivers
