Rails 4.0.4を4.1.0にアップグレードした
Rails 4.1.0が出ていたので、このブログをアップグレードしてみました。 例によって、作業ログを残しておきます。 Riding Rails: Rails 4.1.0: Spring, Variants, Enums, Mailer previews, secrets.yml http://weblog.rubyonrails.org/2014/4/8/Rails-4-1/ (1) GemfileのRailsのバージョンを4.1.0にする (2) 以下のコマンドを実施。 {{{code bundle update rake rails:update }}} -config/routes.rbはスキップ -config/application.rbは特に変化が無かったのでスキップ --（備忘録：4.0.2から4.0.4にアップグレードした時は少し変化があったので修正した記憶があります）
一部報道による「Ruby on Railsにcookie保存関連の脆弱性」について - Qiita
ITmediaの記事が微妙だったので調べて見たのん。(面倒なので箇条書き) 元ネタ Ruby on Railsにcookie保存関連の脆弱性、2000サイトで放置状態 (ITmedia) Ruby on Rails CookieStore Vulnerability Plagues Prominent Websites (原文) 何が問題とされているか (記事の主張) デフォルトでは、cookieにセッションのハッシュ (データ) を保持している。(CookieStore) Rails 2-3の場合は秘密鍵で署名されている = 書き換え不可 Rails 4の場合は暗号化されている = 書き換え・内容の読み取り不可 Cookieを読み取られる可能性がある。 XSS セッションサイドジャッキング: うっかりSSLではない通信をさせると、Rails3以前では機密情報が漏洩する可能性がある。(Ki
Google App Engineでクロスドメイン通信
前回「秋はまだですか」と書きましたが、その日のうちに気温下がったｗ これでちょっと過ごしやすくなったかも。…薄着で寝ててちょっと風邪引きそうになったのは内緒(・ω・) 本題。 クロスドメインでの非同期通信(XMLHttpRequest Level2)をGoogle App Engineで実装したのでメモ。はまったポイントもいくつか書いておきます。 特にハマったのは出力ヘッダ周り。 Access-Control-Allow-Origin これはあちこちのサイトに書かれてますね。このヘッダを「*」で出力してあげると他ドメインからの通信を受け付けるようになります。・・・が、これだけじゃダメなんです。 Access-Control-Allow-Methods こいつを指定してあげないとサーバーが受け付けてくれません。GETならGET、POSTならPOST・・・と指定してあげないといけません。これは
yak shaving で人生の問題の80%が説明できる問題 - bkブログ
yak shaving で人生の問題の80%が説明できる問題 つい最近、 yak shaving （ヤクの毛を刈る）、という言葉を知りました (原典)。これは「一見無関係に見えるけど、真の問題を解くのに必要な問題を解くのに必要な（これが何段階も続く）問題を解くのに必要な活動」という意味の言葉です。 yak shaving は、ようするに「ある問題を解こうと思ったら別の問題が出てきて、それを解こうと思ったらさらに別の問題が出てきて…」ということが延々と続く状況を表しています。ちなみに、ヤクとは毛が長い、牛の一種です。 yak shaving は、以前に覚えた bikeshed と同じくらい便利そうな表現です。というもの、プログラムを書いていると yak shaving 的な状況がすぐに発生するためです。 たとえば、「Amazon のほしい物リストを CSV 形式に変換して Excel で読み
androidのWebViewで取得したCookieをHTTP通信に使う | @blog.justoneplanet.info
そろそろ忘れそうだからメモしておく。 ■WebViewで取得したCookieの保存 @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.web); webView = (WebView) findViewById(R.id.webview); webView.getSettings().setJavaScriptEnabled(true); webView.getSettings().setBuiltInZoomControls(false); webView.setHorizontalScrollBarEnabled(false); webView.setWebViewClient(new WebVie
まこちの技術情報覚え書き WebViewとHttpClientのCookie共有（その２）
前回、HttpClientでリクエスト→クッキー保存→Webviewで共有のパターンを書いたが、 今回はその逆のパターンでWebViewでリクエスト→Cookie保存→HttpClientで共有の方法を紹介する。 WebViewでログインしてから、HttpClientでWebViewと同一サイトで認証が必要な処理等がある場合に そのHttpClientのリクエストが認証をパスする時に使えたりする（あまり需要はなさそうだが）。 今回のパターンの共有には以下のクラスを使う。 ■共有に使うクラス WebViewClient - WebViewのクライアント CookieManager - Cookie管理のクラス(取得／設定等） BasicClientCookie - ユーザが作成可能なCookieクラス CookieStore - HttpClientのクッキーの保管場所 ■ソース １． まず
はてなブログ | 無料ブログを作成しよう
南関東の「いろんなところから富士山が見える」状況に驚きつづけている 大阪から東京に引っ越して３０年以上経つが、じわじわと蓄積されてきた驚きがついに閾値を超えたので筆を執った次第である。正確には「ポメラ DM250を起動してmenuキーを押して新規作成を選んだ」のだが、ポメラを持っていなかったら、さらに驚きが蓄積されていないと…
UIWebViewなどで使うクッキーを再起動しても維持する方法 | Technology-Gym
UIWebViewやASIHTTPRequestではNSHTTPCookieStorageが管理しているクッキーを共有して使うことができる(逆に使わない設定も可能)ので、 起動中はセッションの設定などでクッキーのやり取りを気にしなくてもいいので便利なのですが、さすがに永続化は自動ではやりません そのため、アプリを再起動してもUIWebVIewで表示するサイトのログイン状態を継続したい場合等はNSHTTPCookieStorageからクッキーを取り出して保存して置く必要があります。 NSUserDefaultsを使い単純にファイルとして保存することを考えた場合、クッキーが変化するごとに(iOSだとそもそもキャッチできなさそう)保存するのはI/Oが足を引っ張りそうなので、 起動時と終了時にそれぞれ読み込み、保存処理を行うようにします。 AppDelegateクラスのdelagateメソッドを使
P3Pコンパクトポリシーをコピペするのが流行らないことを祈る | 水無月ばけらのえび日記
なにげにしらなかったんだけど、IEで別ドメインのiframeを読み込むと、そのiframe内のcookieが有効にならない。 そーゆーときは、HTTPのリクエスト時のヘッダーに下記のkey＆valueを出力しておけばOKらしい。 ("P3P", 'CP="CAO PSA OUR"') こーするだけで、あらふしぎ。IEがCookieを保存してくれるじゃん。 ……。 iframeで別ドメインのコンテンツを読み込むと、そのCookieはサードパーティーのCookieとなります。IEのデフォルトでは、ポリシーが定義されていないサードパーティーのCookieは受け入れないようになっていて、P3P (www.w3.org)でポリシーを宣言すれば受け入れられるようになります。 P3Pのポリシーを定義するには、がっつりとXMLを用意する方法もありますが、HTTP応答ヘッダの中に直接書くという方法もあり、コ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://blk.jp/archives/765