Cookie2 とは何か | blog.jxck.io
Intro タイトルを見て「Cookie の新しい仕様か、キャッチアップしよう」と思って開いたのなら、以降を読む必要はない。 Cookie History 2000 年に発行された Cookie の仕様である RFC 2965 では、仕様中に Set-Cookie2/Cookie2 (以下 Cookie2) という 2 つのヘッダが定義されている。しかし 2011 年に改定された現行の RFC 6265 ではそれらヘッダは deprecate されており、実際の Web でこれらのヘッダが交換される場面を、少なくとも筆者は見たことがない。存在すら知らない開発者も多いだろう。 筆者はずっと、この仕様がどのように出てきて、どうして消えていったのかが気になっていた。 Web 上にも情報が少なく、「歴史上の理由で」とか分かったようなことを言ってる人がたまにいるくらいだ。四半世紀前のことなので経緯を
リダイレクトとSame-Site Cookie - teracc’s blog
調べものをしている中で、今さらながらSame-Site Cookieの仕様書を斜め読みした。 ググって最初に見つけた仕様の中で、same-siteは下のように定義されていた。 A request is "same-site" if its target's URI's origin's registrable domain is an exact match for the request's initiator's "site for cookies", and "cross-site" otherwise. Same-site Cookies draft-west-first-party-cookies-07 2.1 (April 6, 2016) 対象（target）と始点（initiator）のサイトが一致すればsame-siteということになる。 リダイレクトを挟むとどうなるか
Cookieのセキュリティ周りでいちばんややこしいDomain属性をしっかり理解する - Qiita
直感的でないのは、自身より下位の階層(example.comの場合のfoo.example.com)のドメインを設定できないことです。また、兄弟関係にある階層のドメインも設定できません。ただしこれらのパターンに関しては、どちらもexample.comを設定すれば送信される対象にはなります。 ということで、CookieのDomain属性は安全です……あれ？ おそらく気付かれたと思うのですが、example.comから見てcomは上位の階層のドメインです。ではexample.comからcomをDomain属性に設定して、.comのすべてのドメインに向けたCookieを設定できてしまうのでしょうか。 現在の仕様(RFC 6265)では、これは制限されています。ブラウザは、comのような公共のドメイン接尾辞(public suffix)1を受け付けないように決められています。2 公共のドメイン接尾
牧歌的 Cookie の終焉 | blog.jxck.io
Intro Cookie は、ブラウザに一度保存すれば、次からその値を自動的に送ってくるという、非常に都合の良い仕様から始まった。 State Less が基本だった Web にセッションの概念をもたらし、今ではこれが無ければ実現できないユースケースの方が多い。 冷静に考えればふざけてるとして思えないヘッダ名からもわかるように、当初はこのヘッダがこんなに重宝され、 Web のあり方を変えるかもしれないくらい重要な議論を巻き起こすことになるとは、最初の実装者も思ってなかっただろう。 そんな Cookie が今どう使われ、 3rd Party Cookie (3rdPC) の何が問題になっているのかを踏まえ、これからどうなっていくのかについて考える。 Cookie のユースケース Web にある API の中でも Cookie はいくつかの点で特異な挙動をする 一度保存すれば、次から自動で送る
safariのcookieポリシー変更により、Criteoの株価が約300億円吹き飛ぶ - adworld’s diary
safari のdesktop browserの規約変更をappleがアナウンスしたことでCriteo(Nasdaq)は300億円ほど、株価が下がった。 これは直近55USDから45USDと約10%株価を落としたことにより、6/13時点で約30億ドルとすると3億USD = 約327億円失ったことになる。 adexchanger.com この理由として、考えれているのが、WWDC 2017で発表されたIntelligent Tracking Prevention（ITP）という機能。 www.gizmodo.jp 要するに 3rd party cookie は1日以内しか保持されない。 1st party Cookie自体は30日以内しか保持されない。また会わせて自動再生動画広告もブロックすることになる。 appleの記事より索引 これにより、 計測および、リターゲティング用cookieが保
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では署名付ける代
セッション管理の要注意点 - Qiita
Webアプリを開発するに当たって、「自分でセッションを書きたい」なんて思う人はおそらく1%もいないでしょう。とはいえ、標準で備わっているセッション機能に問題や機能不足があって、手を入れざるを得なくなる、という場面も多々存在してしまいます。ここでは、セッションまわりでよく問題になる部分について触れてみましょう。 そもそも、セッションとは Webアプリにおけるセッションは、 接続ごとに固有の識別子（セッションID）を割り当て、その接続を使った通信のたびにセッションIDを送受信する セッションIDと紐付ける形でデータを持って、アクセスごとに値を読み出す。 データが書き変われば、書き戻す。 というような流れで、「接続ごとにデータを保存する」ということを実現しています。 セッションとCookie 上の1にあるような「通信のたびにセッションIDを送受信する」ために使われるのがCookieです。ただ、C
Plugins | jQuery Plugins
Can't find a Plugin you are looking for? Check out the jQuery Wiki page. Are you a plugin developer? Please move your plugin over to this site.
JavaScriptでcookieを操作する時はjquery.cookie.jsを使おう - monjudoh’s diary
↓でtxtファイルとしてダウンロードできる。 http://plugins.jquery.com/project/cookie 使い方はデモを触ってみてソース見るとか、 jquery.cookie.jsのソースのコメントの@exampleを見るとかすればいいと思うけど簡単に説明しておくと、 基本的には$.cookie(クッキー名);で値の取得、$.cookie(クッキー名,値);で値の設定が出来て、 第3引数でoptionがいろいろ指定できる。 $.cookie(クッキー名,値,{ expires: 日数, path: '/', domain: ドメイン});とか。 expiresをDateオブジェクトだけじゃなくて日数の数値としても指定できる(というか基本的にこっちを使うはず)。 jQuery pluginだけど$.関数名で使う関数であり、 依存しているjQueryの機能がjQuery.
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
