まこちの技術情報覚え書き WebViewとHttpClientのCookie共有（その２）
前回、HttpClientでリクエスト→クッキー保存→Webviewで共有のパターンを書いたが、 今回はその逆のパターンでWebViewでリクエスト→Cookie保存→HttpClientで共有の方法を紹介する。 WebViewでログインしてから、HttpClientでWebViewと同一サイトで認証が必要な処理等がある場合に そのHttpClientのリクエストが認証をパスする時に使えたりする（あまり需要はなさそうだが）。 今回のパターンの共有には以下のクラスを使う。 ■共有に使うクラス WebViewClient - WebViewのクライアント CookieManager - Cookie管理のクラス(取得／設定等） BasicClientCookie - ユーザが作成可能なCookieクラス CookieStore - HttpClientのクッキーの保管場所 ■ソース １． まず
LocalStorageがおもいのほか便利すぎたのでまとめ - それマグで！
localStorageを使って見た．食わず嫌いでした．すごく便利ですね cookieで保存するより相当便利です． cookie VS localstorage 比較 Cookieの特長 ドメイン毎にデータが保存される．(SameOriginの原則) Stringが保存される． HTTPリクエストで毎回サーバーに送られる JavaScriptからアクセス可能 有効期限がある LocalStorageの特長 ドメイン毎にデータが保存される．(SameOriginの原則) Stringが保存される． HTTPリクエストで毎回サーバーに送られない JavaScriptからアクセス可能 有効期限が特にない 比較まとめ Cookieの特質から、HTTP通信で送る特性を省いたものHTTP通信で送る必要がないので，Expires（期限）も省略される localStorageの保存方法 js> local
rails3.1 with rspec-request , capybaraでcookieを取り扱うには
rails3.1とrspec-requestsをcapybaraで利用した際に、cookieの扱い方が分からなかったのでメモしておきます。 # app/controllers/foo_controller.rb class FooController < ApplicationController def index puts cookies["key1"] cookies["key1"] = '2' cookies.permanent["key2"] = "3" end end # spec/requests/foo_spec.rb describe "foo周辺の仕様" do def cookies Capybara.current_session.driver.browser.current_session.instance_variable_get(:@rack_mock_sess
とほほのCookie入門 - とほほのWWW入門
Cookie とは、以下のようなことを実現するための機構です。 訪問者がそのページに何回訪れたか記録して表示する。 通常モード、フレームモードなど、訪問者の好みを記録しておき、次回訪問時にその好みのモードで表示する。 掲示板やチャットで入力したユーザー名を記録しておき、次回訪問時にユーザー名の入力を省略する。 ログインによるセッションを維持する。 下記の仕様書が公開されています。 RFC2109: https://tools.ietf.org/html/rfc2109 (1997年2月) RFC2965: https://tools.ietf.org/html/rfc2965 (2000年10月) RFC6265: https://tools.ietf.org/html/rfc6265 (2011年4月) 上記のようなデータは CGI などを用いてサーバー側に記録することもできますが、Co
sessionに有効期限を設定する時の試練 - ザリガニが見ていた...。
Railsを使っていて自分で直接cookieを設定するという状況はほとんどなく、大抵はsessionをハッシュ感覚で、便利に利用してきた。Rails2.0以降はsessionの保存先はデフォルトでcookieになり、そのまま利用する限りcookieの有効期限は空欄のままなので、ブラウザを終了するまでsessionは保持されることになる。そして、次回ブラウザを起動すると、期限切れのcookie（その中にsessionが保存されている）は削除されている。 ほとんどの場合、上記デフォルト設定のまま使っていたか、またはrestful_authenticationなどに頼りきりだったので、いざ自分でsessionに有効期限を設定しようとした時、苦労してしまった。とても基本的なことであるのに...。 config/environment.rbでの設定 2009-01-01 00:00:00まで有効にし
Cookie を使ったロケールの切り替え
前回では、サンプルアプリケーション asagao を国際化(i18n)するための第一歩を踏み出しました。 今回は、ロケールを切り替える機能を加えましょう。 まず、app/controllers/application.rb に AVAILABLE_LOCALES という新たな定数を定義します。 class ApplicationController < ActionController::Base AVAILABLE_LOCALES = %w(en ja) # Pick a unique cookie name to distinguish our session data from others' session :session_key => '_asagao_session_id' (省略) 値は、'en' と 'ja' という 2 つの文字列からなる配列です。%w(en ja) と
2.0のcookie session storeを体感する - ザリガニが見ていた...。
Rails2.0の変更点で、セッション(session)データの保存先がクッキー(cookie)になったということを、よく目にする。確認してみると、確かに以前はtmp/sessionsフォルダの中に常にセッションファイルがあり、増え続けていたが、2.0環境にしてからはいつも空っぽだ。そうなると、本当にクッキーに保存されているのか？どのように保存されているのか？実際に覗いてみたくなった...。 クッキーを確認する MacOS X版のFirefox2.0のクッキーは、Firefoxの環境設定 >> プライバシー タブ >> Cookieを表示 ボタン、で表示される。 想像以上のクッキーの多さに驚く。一つずつ見ていてはキリが無いので、検索で「localhast」と入力してみる。 すると一気に絞り込まれ、Cookie名から「_test_slip202_session」が求めるクッキーだと予想できる
Ruby On Rails ピチカート街道 - Rails 2.0・その１１(セッションの情報は全てクライアントのクッキーに書かれる) -
Rails 2.0 がおっしゃいますに、結局セッションに入れる情報ってユーザーIDだけぐらいで短いから、セッションの情報は全部クッキーに入れちゃえばいいんじゃね？みたいに割り切っているようです。 例としては、コントローラ辺りに、session[:food] = 'nikkorogashi' と書いて、そこの処理を通りますと、session オブジェクトが文字列化(Marshal)されてBase64エンコードされてクッキーに保存されます。 要するにクッキーに保存しやすい文字列に変換されます。 決して暗号化されて保存されるわけではありません。 やる気なら誰でも自分のクッキーの情報を見て、session にどういう値が入っているのかを解析できるので、大切な情報（クレジットカード番号とかパスワードとかスリーサイズとか）は session には入れない方がいいです。 どうやってこのようにクッキーを解
cookie をつかったSession Fixation Attack対策
NasuaはRuby on Railsで作ったメモ帳WEBアプリです。って今ではすっかりRailsな話題を取り上げるだけとなってしまいました。。 Ruby On Rails ではログイン前もログインの後も同じセッションCookieを使用するためセッション固定攻撃に対する脆弱性があります。 以前の記事ではログインの後にセッションをリセットする方法で実装を行ってみましたが、試してみたところflashにセットした値が取得できないという不具合がありました。例えば、次のコードでは"logged out !"とい文字列がViewで表示されません。（たぶん使い方が悪いのでしょうが。。） def logout reset_session flash[:notice] = "logged out !" redirect_to(:action => "login_form") end そこで、自前でcooki
はてなブログ | 無料ブログを作成しよう
来年も作りたい！ふきのとう料理を満喫した 2024年春の記録 春は自炊が楽しい季節 1年の中で最も自炊が楽しい季節は春だと思う。スーパーの棚にやわらかな色合いの野菜が並ぶと自然とこころが弾む。 中でもときめくのは山菜だ。早いと2月下旬ごろから並び始めるそれは、タラの芽、ふきのとうと続き、桜の頃にはうるい、ウド、こ…
cookieを保持、参照するplugin - nyaago69のブログ
クッキーの値をDBに格納しておき(Visitorというモデル名にする)、 次回同じユーザがアクセスしたときに格納しておいた情報を参照できるようにするというもののPluginを作ってみました。 マイグレーション まず,cookieを保存しておくテーブルを生成。PluginのRakeで生成できるよう、railsのconfigの接続設定を使ったテーブル生成を行う。 require "active_record" class MigrateVisitors def self.create self.establish_connection MigrateVisitors::CreateVisitors.up end def self.drop self.establish_connection MigrateVisitors::CreateVisitors.down end private def
Cookieセッション、BASIC認証マジパネー - komagataのブログ
Rails検証報告書: プログラマの思索 Railsで特徴的なのは、CookieでHTTP セッションを管理できることだろう。 ここの仕組みが非常に分かりやすい。 Railsの後から付いた機能で一番素敵だと思うのがこの機能です。 「Cookieなんて仕様上は4KBしか保存出来ないんだから寧ろ弱体化してね？」 とか認識されることが多い気がしてならない。 コレ、導入時にも度肝を抜かれて、以降常に、 「ハンパねー、マジCookieセッションハンパねー！」 と脳内のアフロの人が言ってるんですが、大した利点に感じる人は少ないのか、他の言語やWAFで全面採用している例を見たことが無い。 そもそもセッションという言葉自体が複数の処理をまとめた単位という広義の意味とWebアプリケーションで複数リクエストにまたがってサーバー側に保存されるデータという狭義の意味が混在して使われているという事情があってWeb上
Rails 2.0の新しいセッション管理-CookieStore - iビジネス&テクノロジー
(注)この記事の動作確認環境はRC1です。 以前、Railsはデフォルトでtmp/sessionsにセッションファイルを作り続けるため、sessionsフォルダ内のメンテナンスが必要であるという記事を書きました(こちら)。Rails2.0ではデフォルトでCookieStoreという新しいセッション管理機構を用いるため、上記処理の必要がなくなります。 CookieStoreの特徴 クッキーで情報を持つため余分なIOがなくなり高速 セッションファイルの管理が不要 セッションデータが4kを越える場合はCookieOverflowエラー*1 デフォルト設定 environment.rbを確認すると、以下のような記述が追加されています。 config.action_controller.session = { :session_key => '_application_session', :secr
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
/trunk/app/controllers/account_controller.rb - Annotate - Redmine
HTTP Cookies