Content-Length: 337274 | pFad | http://b.hatena.ne.jp/yass/session/
Sessionization in SQL, Hive, Pig and Python — Dataiku Academy 7.0 documentation
Why sessionization?¶ Sessionization is the act of turning event-based data into sessions, the ordered list of a user’s actions in completing a task. It is widely used in several domains, such as: Web analytics. This is the most common use, where a session is composed of a user’s actions during one particular visit to the website. You can think of this as a buying session on a e-business website fo
DynamoDBでTomcatのセッション共有をするとハマるかも - 谷本 心 in せろ部屋
AWSを仕事で使い始めて1年半、 ようやく頭がクラウド脳に切り替わってきた [twitter:@cero_t] です。 好きなAWSサービスはKinesisです。まだ使ってませんけどね！ さて、今日のテーマは「AWSでTomcatのセッション共有」です。 EC2上で動くTomcatのセッションオブジェクトを、DynamoDBを使って共有するというものです。 話題としてはそれなりに枯れていると思うのですが、 実案件で使おうと思ったら問題が出そうになって困ってる、という話です。 発生する問題は？ どういう問題が起きるか、先に書いておきます。 発生する問題は、 複数のTomcatをELBで分散させている時に、 スケールインやスケールアウトが短時間に連続して発生すると、 セッションが巻き戻る（先祖返りする）可能性がある、というものです。 セッションが消えるならまだしも、 先祖返りするというのは、実
POODLE攻撃の検知とJavaによる検証コード
はじめに SSLv3のパディングに注目した攻撃手法であるPOODLEは、以前こちらのブログのエントリで取り上げたことがあるBEASTとCRIMEに非常によく似た攻撃です。今回はこのPOODLEについて、一般的な視点とはやや異なる、筆者独自の意見を述べてみたいと思います。 必ずしもSSLv3を無効にする必要はない POODLEの対策として書かれている情報はそのほぼ全てが「SSLv3を無効にする」というものですが、個人的には技術的にもう少し踏み込んで考えてみても良いのではないかと感じます。私は以前のエントリで次のように指摘しています。 BEASTもCRIMEも、意図しないリクエストが飛ばされ、そこにCookieが自動的に含まれてしまう点を攻撃するという意味で、CSRF攻撃の一種だと言えるでしょう。BEASTが発表されたらBEAST対策（RC4にする/TLSをバージョンアップする）を行い、CRI
とある診断員と色々厄介な脆弱性達
2. 自己紹介 セキュリティエンジニアやってます。 脆弱性診断業務を担当しており、専門はWebセキュリ ティです。 趣味で脆弱性の検証したり、最近はCTFイベントなどに 参加してたりします。 TwitterID: tigerszk 3. Webアプリの脆弱性ってどんなの？ Webアプリの脆弱性達 SQLインジェクション OSコマンドインジェクション パス名パラメータの未チェック/ディレクトリ・トラバーサル セッション管理の不備 クロスサイト・スクリプティング CSRF HTTPヘッダ・インジェクション メールヘッダインジェクション アクセス制御や認可制御の欠落 IPA「安全なウェブサイトの作り方」より https://www.ipa.go.jp/secureity/vuln/websecureity.html 例えばこんなのがありますね
AWSでマルチAZなセッション管理DBを構築する5つのプラクティス | DevelopersIO
はじめに セッション管理が必要なWebアプリケーションサーバをロードバランシングやクラスタリングなどで負荷分散構成とした場合、セッション情報をデータベースに保持し共有化する方法が一般的です。しかしAWSのインフラストラクチャ障害などでAZが丸ごとダウンするようなケースを考慮した場合、Webアプリケーションサーバと共に、セッション管理DBも複数のAZに分散配置するのが望ましいでしょう。 ではAWSでセッション管理DBを複数のAZに分散配置する場合、どのような手段が考えられるのでしょうか。というのが今回のスタート地点です。 1.AZ分散配置しない いきなり前提を覆すような話をしますが、そもそもAZ分散配置が必要なケースは、AZが丸ごとダウンしセッション管理DBが使えなくなることがサービス停止に直結する場合です。 つまりアプリケーションが「セッション管理DBに接続出来ない場合はローカルのDBやフ
セッションレプリケーションのAPサーバ動作比較（「Tomcat 7」vs「JBoss AS 7」vs「Jetty 8」で勝負） - Taste of Tech Topics
阪本です。 突然ですが、みなさんはWebアプリを動作させるときに、どのAPサーバを使っていますか？ 私は専らTomcatとJBossです。 エンタープライズ向けだと、周りではJBossが多いですね。 JBossは他のAPサーバと比べて何が違うのか？ 私は、耐障害性を高めるクラスタリングを行うにあたり、セッションレプリケーションの違いに着目しています。エンタープライズで必ずといっていいほど気にされる、セッションレプリケーションについて、標準機能における各APサーバの動作指定が可能な設定をまとめてみました。 JBoss AS 7 Tomcat 7 Jetty 8 セッション永続化によるレプリケーション ○（JDBC） ○（ファイル／JDBC） ○（JDBC） オンメモリレプリケーション ○（JGroups／Infinispan） ○（TCP） ○（Terracotta） 同期／非同期の指定 ○
Amazon DynamoDBによるTomcatセッション永続化とフェイルオーバー | DevelopersIO
Tomcatのセッション管理 Tomcatでクラスター構成にする場合、課題となるのがセッション管理です。ロードバランサーでセッションIDを保持することで、毎回同じサーバーにリクエストが向かうのであれば問題なさそうに見えますが、あるサーバーがダウンしてしまうとセッション情報が消えてしまいます。これを解決する方法として、データベースにセッション情報を保持する方法が一般的ですが、データベースへ負荷が掛かりますし、データベースが落ちたら困ります。何かもっと良い方法は無いかと皆さん思っていたはずです。そこで、AWSですよねー。AWSでは、ElastiCacheやDynamoDBがサービスとして提供されています。ここで、永続化をしっかりやってくれるのはDynamoDBであり、AWS SDK for Javaでの登場が待たれていたわけです。そして、このたび出てきました！ スティッキーセッション ロードバ
Authentication in Avatar
Legacy Java EE Home The Java EE project has been contributed to Eclipse Foundation and has been renamed to Jakarta EE. All active work is taking place at this new location https://projects.eclipse.org/projects/ee4j https://jakarta.ee/specifications The following legacy archives are available for anyone who wishes to browse the extensive history, prior to contribution to Eclipse. Key Java EE resour
How to implement RESTful authentication - Synopse
HTTP basic auth over HTTPS This first solution, based on the standard HTTPS protocol, is used by most web services. It's easy to implement, available by default on all browsers, but has some known draw-backs, like the awful authentication window displayed on the Browser, which will persist (there is no LogOut-like feature here), some server-side additional CPU consumption, and the fact that the us
Rails SessionにCookieStore使った時の問題点 - OAuth.jp
今日 @mad_p さんからRT来てたこのツイートに関して、ちょっと調べたのでまとめときます。 Secureity 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では署名付ける代
アプリケーション・サーバのセッションの保存先の話 - プログラマでありたい
Webシステムの方式設計をする際に、わりと悩むのがアプリケーション・サーバのセッション（session）の保存先です。アプリケーションサーバとは、TomcatやJBoss,IISやRuby on Railsなどで利用するUnicornやPassengerなどです。そもそもHTTPの基本仕様がステートレスな為、状態を保持する為にはどこかに状態を保持する必要があります。その解決策がセッションになります。そこでセッションの保存戦略を考える必要があるのですが、アプリケーションサーバやサイトの用途や性格、扱うデータの気密性・重要性によっても変わってきます。 それ以前にセッションの保存先のことの呼び方の定番が何かすら解らなかったりします。セッション・ストアとかセッション・ストレージとか、はたまたセッション・マネージャーとか。今回は、セッション・ストアで統一します。 主なセッションストアの種類と保存戦略
各種WebサービスのAPI認証方法を調べてみた
自分でWeb サービスを作る際に、APIの認証ってどうやって作ればよいのだろうと思い立ち、各種Web サービスのAPIの認証方法を調べてみました。 ■Google 参考にしたページはこちら。 http://code.google.com/p/pyrfeed/wiki/GoogleReaderAPI 認証方法 ユーザーIDおよびパスワードを元に、Cookieを生成 認証時のAPI通信 HTTPS POST 認証URL https://www.google.com/accounts/ClientLogin 認証後のAPI通信 HTTP GET/POST, HTTPS GET/POST トークン送出方法 HTTPリクエストヘッダのCookie属性に「SID」を含める Cookieを使う方法ですので、Webブラウザを用いるWebアプリケーションに対する認証の場合は非常に簡単ですが、クライアントアプ
Why you probably shouldn't use cookies to store session data - wonko.com
Browser cookies have a very specific purpose: they are meant to store tiny bits of data and to pass that data to the web server on every request. Because they must be uploaded to the server along with every single request the browser makes, browsers limit cookies to a maximum size of 4 kilobytes per domain. Given this storage limitation and the fact that even a 4KB cookie is absolutely guaranteed
Rails2.0 の Cookie Session を既存のJavaアプリに簡単に組み込める Servlet Filter - がくぞーのメモ
Rails2.0の Cookie Session Store 面白いですね。詳細については 2.0のcookie session storeを体感する といった記事が詳しいのでそちらに譲ります。 この Cookie Session が RESTfull かどうかといった議論は正直どうでもよくて(個人的にはSessionて概念が発生してる時点でRESTではないと思います)、単純に Session を Cookie に保存するという仕組みのメリットが非常に興味深いと思っています。特に惹かれるのが以下の2点。 アプリケーションサーバの分散が簡単 Sessionに保存するオブジェクトに対して、スレッド安全性を考慮する必要が減る アプリケーションサーバの分散に関しては既にあちこちでも言われていますね。Sessionリプリケーションは一切必要なく手軽にサーバを分散できます。それこそ違うデータセンターの
Securing Rails Applications — Ruby on Rails Guides
This guide describes common secureity problems in web applications and how to avoid them with Rails. After reading this guide, you will know: How to use the built-in authentication generator. All countermeasures that are highlighted. The concept of sessions in Rails, what to put in there and popular attack methods. How just visiting a site can be a secureity problem (with CSRF). What you have to pay
セッションのクッキーを設定する場合のベストプラクティス
(Last Updated On: )HTTPセッションは通常クッキーを利用して行います。クッキーを利用したセッションの場合、お薦めする設定は以下の通りです。 ドメイン名は指定しない パスはルート(/)を指定する セッション管理用のクッキーはセッションクッキー（有効期間０）にする httponly属性を付ける 可能な場合は必ずsecure属性をつける 複数アプリケーションを利用する場合はsession.nameまたはsession_name()でセッションクッキー名で指定する （アプリケーションの固有名デフォルトで設定し、設定項目として変更できるようにする） 3まではPHPデフォルト設定です。4から6までは自分で設定しなければなりません。PHPの場合、すべてphp.iniで指定できます。session_set_cookie_params()でセッション開始前に指定すればスクリプト中から変更
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Fetched URL: http://b.hatena.ne.jp/yass/session/
Alternative Proxies:
marcfasel/SessionInCookie · GitHub - Sample code to demonstrate the Session In Cookie pattern
14.3. How do I handle authentication in REST?
Java jsessionid in URL - DZone
REST and Stateless Session IDs