shell script for S3-upload via curl using AWS version 4 signatures
shell script for S3-upload via curl using AWS version 4 signatures This is a more modern version of this script, switching to AWS version 4 signatures that are mandatory for AWS regions created after January 2014. It also works with older regions as they seem to support the new signature format, as well. The script's interface is a bit easier and more intuitive, too, and allows setting the access
Node.jsでAWSのAPIで認証するやつ書いた - ✘╹◡╹✘
https://github.com/r7kamura/aws-signer-v4 Amazon API GatewayのREST APIを利用したかったんだけど、Node.js用のaws-sdkにはまだその機能が入っていないこともあり、自分で認証するためのライブラリを書いた。リクエストのメソッド、URL、ヘッダ、ボディ、AWSのAccessKeyID、SecretAccessKey、リージョンを、決められた手順に従って加工し、Authorizationリクエストヘッダに入れることで認証が通るようになる。その決められた手順を実装した。詳しい仕様は AWS Signature version 4 のページに記載されているがほとんどの人間は読む必要は無い。自分でこのロジックを実装したいなら、JavaScriptの場合は aws-sdk-js/lib//signers/v4.js にAWSのSD
JK・おっさんプロトコル - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? JKとおっさんの間で、個人情報を一切漏らすことなく円滑なコミュニケーションが行えるように工夫したプロトコルです。現在は次の二つのプロトコルがありますが、ニーズに合わせてもっと色々考えたいと思っています。 高校生判定プロトコル 登場人物 ここには次のような登場人物がいると仮定します。 JK 自分が高校生であることを証明したいが名前や住所、所属する学校などは保護したい おっさん ある人間について、その人間の性別や年齢といった個人情報はどうでもいいが、高校生であるということは確定させたい このような仮定があるので、例えばJKが、JKの所属する
FacebookのOAuthのアクセストークンについて - Study08.net 対シンバシ殲滅用人型機動兵器
FacebookのOAuthのトークンについての覚え書き。 最近では、Facebook や Twitter の OAuth認証を介して、ログイン機能を提供するWebサービスが大分増えてきましたよね。しかも、ID/PASSでのログインとは別に、おまけ程度にあるのではなく、Facebook or Twitter でしかログインできないなんてサービスもちらほらあります。 FacebookのOAuth認証を通して手に入るユーザーのアクセストークンは、ユーザーがパスワードを変更したタイミングとかで無効になるので、認証するたびに新しいトークンになってたら、差し替えておいた方が良いんじゃないかなという話を長ったらしくします。 Facebook のOAuth認証のフロー 割と適当に書いたシーケンス図(ぽい)もので確認しましょう。 アプリケーションの要件によって、異なると思いますが、Webアプリケーションだ
OpenIDの仕組み・安全性と危険性
少し思う所があってメモ OpenIDが出来る事 ユーザーが「あるOpenIDプロバイダにアカウントを持っていること」をウェブアプリに証明する 基本的にはたったこれだけ。OAuthとの違いウェブアプリに何らかの権限や、ランダム生成された識別子以上の情報を渡すことはない。 OpenIDログインを利用するウェブアプリ（リライングパーティー）が知ることができるのは ・ユーザーがどのプロバイダのIDを持っているか ・ユーザーの所有する識別子（乱数） OpenIDを発行する側（OpenIDプロバイダと呼ばれる）が知ることが出来るのは、 ・ユーザーがどのウェブアプリ（リライングパーティーと呼ばれる）にアクセスしたか だけになる。正しく実装されたOpenIDでは、OpenIDプロバイダにどのような情報が登録されているか（メールアドレスやパスワードなど）は、リライングパーティにはわたらない。 仕組み Ope
OpenID ConnectのSelf-Issued OP(OIDC SIOP)の話 - r-weblife
おはようございます、ritouです。 OpenID Connect Messagesの仕様で定義されてるSelf-Issued OpenID Providerについてのお話です。 いきなり参考リンク 英語読める人は仕様読めばよい。 仕様(English) : http://openid.net/specs/openid-connect-messages-1_0.html#self_issued 参考になりそうな資料 by @nov : Self isssued-idp ざっくり説明 こんな感じです。 OS(PC, モバイル端末)やブラウザ内で動作し、openid://で呼び出される ユニークなRSAやECDSAとかのprivate/publicな鍵ペアを生成して安全に管理する クライアント(Webサービスやアプリ)からリクエストを受けたら署名付のID Tokenを返す というところです。
SESのDomainのverifyについて - temporal's diary
SESのDomainのverifiyでは何をどう設定すればよいのか、設定にどれくらいの時間がかかるのかという点にとまどうことがあります。 SESでは送信元となるEmailアドレスについて、あらかじめverify(有効性の事前確認)をされていなければなりません。verifiedされたEmailアドレスからのみメールを送信することが可能となります。verifyを実行すると対象となるアドレスに対して、SESから確認のメール(Amazon SES Address Verification Request)があり、メールの中にあるURLにアクセスすることで有効性の確認が行われ、verifiedになります。 複数のEmailアドレスからメールを送信する場合は、それぞれのEmailアドレス毎にこの作業を行うのは面倒です。DomainをverifyすればそのDomainからのメールはすべて送信可能となりま
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Customer Identity and Access Management – CIAM | Janrain
http://hueniverse.com/2012/07/26/oauth-2-0-and-the-road-to-hell/
AB/Connect WG recommends for the 2nd Implementer’s Drafts | OpenID
#idcon 15th ritou 2factor auth
OmniAuth、Warden、Sinatraを連携しよう « blog.udzura.jp