概要 JWTを認証用トークンに使う時に調べたことをまとめます。 JWTとは JWTはJWSやJWEの構造の中にエンコードして埋め込まれるJSON形式のclaimのセットです。 一般的にはJWS形式のJWTが使われるのでそれを前提に進めます。 JWS形式のJWTは以下のフォーマットです。 {base64エンコードしたheader}.{base64エンコードしたclaims}.{署名} 以下の特徴があります。 発行者が鍵を使ってJSONを署名（or HMAC）し、トークンとして扱う。 暗号化ではないので、JSON の中身は誰でも見られる。 発行者は鍵を使ってメッセージの検証ができるので、改竄を検知できる。 以上の点からトークンとして向いているため、認証トークンとして用いられるようになってきました。 Cookieとの認証フロー比較 ref: Cookies vs Tokens. Getting
はじめに ログイン認証が必要なWebViewアプリをWKWebViewを使って作る機会がありました。その際にCookie周りで困ることがあったので、共有のために記事を投稿します。 実現したい仕様 ネイティブで作ったログイン画面に認証情報をいれてログインすると、WebページのTOP画面に遷移 TOP画面以降は認証状態を保ったまま、WebView内で様々な画面に遷移 アプリ側は技術的にはこんな感じでいける?? アプリ起動時に、ネイティブで作ったログイン画面を表示 認証情報をリクエストパラメーターとしてログインAPIを叩く ログインAPIでtokenをアプリ内部に保持(tokenは例えばPHPなら、PHPSESSIDに該当) WebViewを扱うViewControllerに遷移して、WKWebViewをinitしてaddSubView init時に、WKWebViewにtokenをCookie
What Is A Token?Tokens are pieces of data that carry just enough information to facilitate the process of determining a user's identity or authorizing a user to perform an action. All in all, tokens are artifacts that allow application systems to perform the authorization and authentication process. New to identity concepts? Read Authentication vs Authorization to get started. Common identity fram
(from http://www.irasutoya.com/2012/11/blog-post_27.html ) 先日行った社内勉強会で、cookieの仕様（主にRFC6265）やセキュリティ（主にCSRF）について話したので、その内容をまとめました。 1st party/3rd party cookieについてや、CORS時のpre flightについても記述しています。 はじめに 但し書き cookieの仕様 cookieの概要 cookieの属性 cookieのブラウザ毎の差異 Path 属性 domain 属性 1st party cookieと3rd party cookie 動作確認 動作準備 3rd-partyの場合 1st-partyの場合 セキュリティ Ambient 権限 pre flightの仕組み 動作サンプル pre flightが飛ばない場合 pre fli
こちらは ピクシブ株式会社 Advent Calendar 2014 の12/16の記事です。 こんにちは、エンジニアの@dnskimoです。 先日、はじめてCORSを実装する機会があったので、覚書がてらまとめておきたいと思います。 CORSとは Cross-origin resource sharingの略です。 読み方は「コルス」でいいんでしょうか？ Same-Origin Policyに弾かれずに、異なるドメイン間でリソースを共有する仕組みです。 2014年1月にW3C勧告になり、JSONPに替わる方法として徐々に普及してきているようです（要出典）。 アクセスコントロールの仕様も定義されているので、特定のサイトからのみ利用可能なAPIを作る際などに便利です。 JSONPのような「裏ワザ」的な方法ではないところも個人的に好みです。 詳しいことはネット上に素晴らしい記事がたくさんあるので
![CORSでハマったことまとめ - pixiv inside [archive]](https://cdn-ak-scissors.b.st-hatena.com/image/square/70054759c3787b5c8b89449617d22d699ef3b8f9/height=288;version=1;width=512/https%3A%2F%2Fsiteproxy.ruqli.workers.dev%3A443%2Fhttps%2Fcdn.image.st-hatena.com%2Fimage%2Fscale%2F4393f2761db895fd0a5106a3761d1fe12d734abe%2Fbackend%3Dimagemagick%3Bversion%3D1%3Bwidth%3D1300%2Fhttp%253A%252F%252Fcdn-ak.f.st-hatena.com%252Fimages%252Ffotolife%252Fd%252Fdevpixiv%252F20141216%252F20141216151227.jpg)
micro_dmp_handson.md #「Mastering DMP」 この本について Play FrameworkでマイクロDMPを作成します 用意するもの OS: Windows or Mac AP: Play Framework DB: MariaDB or MySQL HTTP Server: Nginx IDE: Eclipse or IntelliJ Java8 Chrome EditCookieプラグイン この本のレッスンで作成できるもの MicroDMP AP Server ・・ Play Framework(Java) Nginx Server ・・ Browser Request -> Nginx -> mDMP mdmp.js・・ 3rd Party Cookie を扱うJavaScript 第1部 Cookieを利用したDMPを作ろう 0章 開発準備 この本で題
We just added a new updated article that covers the same topic. You can find it here: Cookies vs Tokens: The definitive guide. Introduction There are basically two different ways of implementing server side authentication for apps with a frontend and an API: The most adopted one, is Cookie-Based Authentication (you can find an example here) that uses server side cookies to authenticate the user on
『MarkeZine』が主催するマーケティング・イベント『MarkeZine Day』の 最新情報をはじめ、様々なイベント情報をまとめてご紹介します。 MarkeZine Day
TARGETING正確かつ豊富なデータで きめ細やかなターゲティング 独自データによるユーザーの属性や興味関心などの精緻なセグメントで的確にアプローチが可能です。 MARKETINGデータが導くインサイトでマーケティングを加速 広告配信前に最適な打ち手を把握することや、広告配信後に詳細な効果の見える化を可能にします。 様々な観点から ユーザーインサイトと効果を分析 ※上記は一例です AD VERIFICATIONアドベリフィケーションツールを デフォルトで搭載 ブランド毀損やアドフラウドのリスクを排除した広告配信を実現。ビューアブル計測にも対応しています。 Brand Safety クライアントのブランド毀損を招きかねない粗悪な掲載面や不適切なページへの広告配信を未然に防ぎ、毀損リスクを排除。クライアントのブランド価値を保護します。 Anti-Fraud 不正ボットへの広告配信や不正な広告
cookiesync.md Cookie Syncの調査メモ RTB周りで使われているというCookie Syncについて興味がわいたので調べてみる。 http://www.scaleout.jp/26992/ DMP-DSP間 Quoraから。 http://www.quora.com/How-does-cookie-sync-work-between-DMP-and-DSP クライアントはWebサイト上に DMP Universal Container Tagを設置する クライアントが設置したTagの中にDSPのピクセルが置かれる クライアントのブラウザには、DMPとDSPが発行したCookieを受け取れる このときにDMPとDSPはユーザーIDを振ることができる 「ここで同期」 DMPがDSPを呼び出すときにクエリストリングを用いて自身のIDを渡す DSPはDMPのCookie ID
Swiftype Swiftype <%= link_to 'Features', features_path %> <%= link_to 'Solutions', solutions_path %> <%= link_to 'About', about_path %> Recent posts sign up WebServerUid: Easy Unique Browser IDs for Rails & Better Analytics Andrew Geweke on February 24, 2014 at 3:13 PM Here at Swiftype, one of the ways we work hard to improve our product is to use various analytics tools (including our own searc
概要「nginxで認証用proxyサーバを作成」をもとに設定 全てのアクセスでわざわざPHPを呼び出すのは非効率なので、セッションの判定部分はNginxのみで解決することにより高速化可能 http://blog.asial.co.jp/1046 GOALcookieにauthidというキーで、ランダム値を保存 memcachedにランダム値をキーにして、認証状態(1)をセット cookieとmemcachedの値から、ログインしているかどうかを判定する 今回はランダム値を”abcde”とする できればサードパーティのモジュールevalは利用しない方向で検討する 各バージョンroot@hostname:/home/shimizu# uname -a Linux hostname 3.2.0-4-amd64 #1 SMP Debian 3.2.54-2 x86_64 GNU/Linux roo
I set cookies with the code suggested in the docs: from flask import make_response @app.route('/') def index(): resp = make_response(render_template(...)) resp.set_cookie('username', 'the username') return resp But how do I remove them? There is no remove_cookie method. I tried: if request.cookies.get('sessionID'); request.cookies.pop('sessionID', None) but it turns out that the request.cookies ob
この連載の第2回で、Web広告とアプリ広告の効果測定方法の手法の違い、およびアプリの広告効果測定を行うためのSDKの話を紹介しました。今回は、広告効果測定におけるプライバシーの話に踏み込んでみたいと思います。 広告効果測定とプライバシー 広告効果測定とプライバシーの保護は非常に密接な関係にあります。効果測定を行うということは、ユーザがどの広告を経由して流入して来たかを特定するということであり、つまりユーザの行動追跡を行うということです。 弊社も「Force Operation X」（以下「F.O.X」）という広告効果測定ツールを自社で開発し、広告主へ提供しているベンダの立場として、広告主の「ユーザの動向を正確に把握したい」という思いと、ユーザの「個人情報を勝手に扱われたくない」という思いを両立する必要があります。 プライバシー保護の観点では、いわゆる個人情報を扱わない、つまり個人を特
今日Yahoo!知恵袋で以下の記事を読みました。 質問 トラッキングの拒否（Do Not Track）って設定しておいた方が良いんでしょか。 説明読んでも今ひとつ分からないんですが、ただｳｪｰﾌﾞ追跡と留まり時間、広告の類のこと？ 再度アクセスする時にトラッキングの拒否を設定していると面倒臭いんでしょうか？ ベストアンサーに選ばれた回答 ブラウザで、トラッキングクッキーを拒否する設定ですね。 トラッキングクッキーは名前の通り、ブラウザでの操作、すなわち、サイトの何処をクリックしたか、どんなサイト・ページを見たといった、ネットでの行動を監視・追跡をする為のモノです。 【中略】 トラッキングされるのがイヤ、気持ち悪いと考えるならば、トラッキングの拒否（Do Not Track）の設定をONとすれば、ブラウザ側で適時、トラッキングクッキー（と思われるモノ）を拒否してくれるかと。【後略】 http
Do Not Track 実装ガイド 第 1 章 : Do Not Track の概要 1 背景 Do Not Track の仕組み トラッキングを巡る議論 プライバシー技術と Do Not Tack » プライバシーポリシー » オプトアウト Cookie と AdChoices » Do Not Trackと法律 第 2 章 : ケーススタディ 11 ケーススタディ 1 : 広告会社 ケーススタディ 2 : テクノロジープロバイダ ケーススタディ 3 : メディア企業 ケーススタディ 4 : ソフトウェア企業 考慮すべきその他の問題 » オプトアウト Cookie » IP アドレス » モバイル端末 » ファーストパーティのホストに設定されるサードパーティ Cookie DNT 対応フローチャート 第 3 章 : チュートリアル 20 チュートリアル 1 : JavaScript
Web開発者のためのサードパーティCookieやらトラッキングやらの問題点について三回ぐらいに分けて書きます。 この文章は個人的に書いていますので、おい、お前のところのサービスがサードパーティCookieに依存してるじゃねーかというツッコミがあるかもしれないが、そういうことを気にしているといつまで経っても公開できないという問題が出てしまうので、そんなことはお構いなしに書く。ちなみに例外なく自社サービスに対してもサードパーティCookieに依存するな死ねと言っている。これはWebプログラマー観点で、自分がサービス開発に関わる上で知っておかねばならないだろう知識として十数年間だらだらとWebを見ていて自然に知っていたものと、あるいは興味を持って率先して調べたものが含まれている。ググッて直ぐに分かる程度の用語の定義的なことは書かない。あくまでWebサイト制作者側からの観点なので、ブラウザ開発関係
前回 http://d.hatena.ne.jp/mala/20111125/1322210819 の続きです。 前回のあらすじ ブラウザベンダーはサードパーティCookieをデフォルトでオフにしたかったんだけどお前らがサードパーティCookieに依存したサイト作るし使うからオフに出来なかったんだよ!!!!! といった事情を踏まえた上でWebアプリケーションにおけるサードパーティCookieの利用の歴史について書きます。前提知識の共有が済んだので、ここからはある程度個人的な意見も含まれます。実装面での技術的な内容も含みます。 サードパーティCookieが必要とされてきた歴史 広告のためのトラッキングCookie以外にも、サードパーティCookieに依存したサービスが数多く存在してきた。個人的に把握しているいくつかのサービスについて時系列で述べる。ついでに広告業界の流れについても重要なのを幾
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
