技術/HTTP/REST設計思想の "Stateless" との付き合い方 - Glamenv-Septzen.net
id: 1350 所有者: msakamoto-sf 作成日: 2015-02-11 21:34:52 カテゴリ: HTTP プログラミング [ Prev ] [ Next ] [ 技術 ] RESTfulなAPIやWebアプリケーションを開発する際に、一つの疑問が生じる。 RESTでは「ステートレス」を重視して、サーバサイドでのセッション管理ではなく、クライアント側で認証情報や状態を保持して、サーバに都度送る方式を唱えている。これはHTTPで実装するなら、Cookieを使ったセッション管理ではなく、BasicやDigest認証など、HTTP認証を使うことになる。 しかし現実問題として、モダンなWebサイトでBasic/Digest認証を扱うことはなく、サーバサイドのCookieを使ったセッション管理を使うことになる。 RESTにおいて、ステートレスという特性と、現実のセッション管理をどう
java における sticky session の話 - tokuhirom's blog
HTTPのセッションをRedisのようなバックエンドに持たせて毎回参照するような構成と、それに加えてローカルオンメモリキャッシュとSticky sessionでさらにnear cache挟んで高速化するの、どっちがベターか論争みたいなのって過去にあるのかな — Takayoshi Kimura (@nekop) November 17, 2014 Javaだとローカルオンメモリキャッシュ簡単だけど、マルチプロセスモデルなスクリプト言語とかだとローカルキャッシュ共有面倒だからバックエンド一択というのが多数派になる — Takayoshi Kimura (@nekop) November 17, 2014 このへん見てて考えたことのメモ｡ 実際､Java のシングルサーバーからスケールアウトさせる場合は｢sticky session によるオンメモリキャッシュ → redis かなにかのバック
How to bake delicious cookie (RESTful Meetup #03)
Toru Yamaguchi gave a presentation on advanced cookie usage. He explained the differences between host cookies and domain cookies, and how the path attribute can be used to control where cookies are sent. He discussed how JSON web tokens (JWT) can be used for login sessions by embedding user agent information. Finally, he mentioned how transparent session state cookies allow for single logout betw
間違いだらけのHTTPセッション管理とその対策
(Last Updated On: 2018年10月12日)HTTPセッション管理はWebセキュリティの中核と言える機能です。Webセキュリティの中核であるHTTPセッション管理に設計上のバグがある事は少なくありません。今回のエントリはPHP Webアプリ開発者ではなく、主にWebフレームワーク側の開発者、つまりPHP本体の方に間違いがあるという話しです。Webアプリ開発者の回避策も紹介します。 まずセキュリティの基本として「入力のバリデーションを行い、正当な入力のみを受け入れる」があります。しかし、PHPに限らず多くのセッション管理機構は当たり前の「入力のバリデーションを行い、正当な入力のみを受け入れる」を行っていません。セッションIDの再生成（リセット）も不完全な物が多いと思います。 参考： 知らないと勘違いする「合成の誤謬」の罠 開発者は必修、SANS TOP 25の怪物的なセキュリ
Rails SessionにCookieStore使った時の問題点 - OAuth.jp
今日 @mad_p さんからRT来てたこのツイートに関して、ちょっと調べたのでまとめときます。 Security Issue in Ruby on Rails Could Expose Cookies http://t.co/JlsXVEn4rZ — Ruby on Rails News (@RubyonRailsNews) September 25, 2013 前提条件 Railsではデフォルトでsessionをcookieにのみ保存して、DBなりmemcacheなりのserver-side storageには何も保存しません。 これがCookieStoreとか呼ばれてるやつです。 この場合のsession cookieは、Railsのsession object (Hash object) をMarshal.dumpしてそれに署名を付けたtokenです。 rails 4では署名付ける代
ステートレスなPlay2でログイン状態を管理する - C Sharpens you up
Play framework 2.x Java and 1.x Advent Calendar 2013*1の20日目（5日ぶり4回目）です。 寄稿予定表をみると、明日担当のgakuzzzzさんの内容とかぶってしまっている可能性がとても高いのですが、Play1とPlay2の違いがあるので許してもらえないものでしょうか。 さて、JavaEEにもPHPにもASP.NETにもあるのにPlay! frameworkにはないものはと問われれば。 セッションですね。アクセスしてくる閲覧者を識別して、閲覧者別にデータを保持できる容器です。Play!にはこれがありません（ドキュメントにはセッションと称する機能の記載がありますが、これは一般には一時クッキーと呼ばれるものです）。 Play!のキャッチフレーズ「ステートレス」というのがまさにセッション機能を持たないことを意味しています。機能が欠けていることが特
Apache Proxy Balancer上でSet-Cookieするには : funasaki
前々回の記事で、スティッキーセッションの話をしました。 そのときの記事は、APサーバ側で識別子を仕込むというものでした。 その識別子は、Tomcat の場合だと、jvmRoute という識別子を server.xml 上で指定していました。 今回の方法は、AP 側でその識別子を仕込まないでスティッキーセッションを実現する方法の紹介です。 具体的には、ロードバランサ（LB）上で、その識別子を Cookie に仕込みます。 調べていると、Amazon Elastic Load Balancing では、この方法が出来るので、Apache Proxy Balancer でも出来るんじゃないかなーと思って、調べていたら、やはり出来ました。 Apache Proxy Balancer 上の httpd.conf に下記のように記載します。 Header add Set-Cookie "ROUTEID
アプリケーションサーバをダウンさせる時に、セッションをどうするか？ : funasaki
前回の書き込みから随分時間が経過してしまいました。 引き続き、ロードバランサ＆セッションネタを続けます。 下記のようなパターンを考えます。 アプリケーション(AP)サーバが３台立っているとします。（サーバ1,2,3） そのフロントにロードバランサが立っていて、アクセスを割り振っています。 そこで、サーバ1をダウンさせる場合、サーバ1 が持っているセッションはどうなるか？ APサーバ間で、セッションレプリケーションを頻繁に行っていれば、サーバ1がダウンしても、他のサーバ2,3で同じセッションに接続できます。セッションレプリケーションを、サーバをダウンさせるタイミングで実行するように、AP 側で設定することも可能です。セッションレプリケーションにより、シリアライズされたセッション情報を DB に格納する手段もあります。 セッションのデータサイズが大きく、全 AP サーバ間で共有してしまうと、リ
LBを経由して、毎回同じAPサーバへアクセスさせるには？（Sticky Session） : funasaki
ロードバランサ(LB) を立てて、バックエンドに複数のAPサーバを立ててみたけども、LBを経由して毎回同じAP サーバへアクセスさせたい時、ありますよね。APサーバ1に、一度アクセスしていて、そのセッションが保持されている場合です。そんな時に、APサーバ2にLBからアクセスが振られてしまうと、またログイン画面が表示されてしまう、というパターンに陥ることがあります。 これをLBで、どのように調整しているかというと、APサーバ1,2ごとにそれぞれ異なる識別子を持たせます。 例えば APサーバ1 には jvm1 を、APサーバ2 には jvm2 という値を識別子を持たせます。そして、個々のユーザの Cookie 内に仕込まれる JSESSIONID の末尾にこれらの値を挿入させます。( Tomcat 等のアプリケーションサーバ側の設定で、自動的に挿入されます。） ユーザ１の JSESSIONI
Amazon DynamoDBによるTomcatセッション永続化とフェイルオーバー | DevelopersIO
Tomcatのセッション管理 Tomcatでクラスター構成にする場合、課題となるのがセッション管理です。ロードバランサーでセッションIDを保持することで、毎回同じサーバーにリクエストが向かうのであれば問題なさそうに見えますが、あるサーバーがダウンしてしまうとセッション情報が消えてしまいます。これを解決する方法として、データベースにセッション情報を保持する方法が一般的ですが、データベースへ負荷が掛かりますし、データベースが落ちたら困ります。何かもっと良い方法は無いかと皆さん思っていたはずです。そこで、AWSですよねー。AWSでは、ElastiCacheやDynamoDBがサービスとして提供されています。ここで、永続化をしっかりやってくれるのはDynamoDBであり、AWS SDK for Javaでの登場が待たれていたわけです。そして、このたび出てきました！ スティッキーセッション ロードバ
アプリケーション・サーバのセッションの保存先の話 - プログラマでありたい
Webシステムの方式設計をする際に、わりと悩むのがアプリケーション・サーバのセッション（session）の保存先です。アプリケーションサーバとは、TomcatやJBoss,IISやRuby on Railsなどで利用するUnicornやPassengerなどです。そもそもHTTPの基本仕様がステートレスな為、状態を保持する為にはどこかに状態を保持する必要があります。その解決策がセッションになります。そこでセッションの保存戦略を考える必要があるのですが、アプリケーションサーバやサイトの用途や性格、扱うデータの気密性・重要性によっても変わってきます。 それ以前にセッションの保存先のことの呼び方の定番が何かすら解らなかったりします。セッション・ストアとかセッション・ストレージとか、はたまたセッション・マネージャーとか。今回は、セッション・ストアで統一します。 主なセッションストアの種類と保存戦略
Play! framework 概要 Tipsもあるよ！ - ikeike443のブログ
Play! Advent Calendar 2011 一日目ということで、軽めの話をします。 おさらい：Play!とは Play!はJavaで軽量に素早く開発できるフレームワークです。 Play!についてよく知らない人が圧倒的多数だと思いますので、ものすごく簡単に説明しますね。 Play!はJavaEEの仕様を捨ててWebとフォーリンラブすることに決めたフレームワークなので、Servlet特有の変なセッション仕様なんてないですし、えっと、セッションレプリケーションってなんですか？ ってなノリのフレームワークです。 もちろん、warにパッケージングする必要もないです。 EclipseのECJを使って動的コンパイルを行うことで、ほんとうの意味でのホットデプロイを実現しています。というか、デプロイしないんですけど。。まあ、ほとんどスクリプト言語のようにJavaを使えるわけです。再起動無しで変更が
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Vert.x Session Manager Modules | Campudus
Play framework 2.x Java and 1.x Advent Calendar 2013 21日 Play1 でうっかり Session Fixation を引き起こしてしまう状況と対策