JWT・Cookieそれぞれの認証方式のメリデメ比較 - Qiita
JWTとは JSON Web Tokenの略。ジョットと読むらしい。 ざっくりいうとJsonに電子署名を加え、URL-Safeな文字列にしたTokenのこと 正確にいうと、電子署名を使用する方式はJWS（JSON Web Signature）と呼ばれ、別途暗号化を使用するJWE（JSON Web Encryption）も存在する。よく見かける説明はJWS方式のほう。 JWS方式の場合、電子署名であり暗号化ではないため、中身を見ることは可能。但し改ざんはできない、という仕組み。 実際のユースケースで言うと、サーバ側で認証情報が入ったJsonを加工（電子署名を加える等）し、JWTにしたのち、それを認証Tokenとしてクライアントに渡す。クライアントはそのTokenを認証Tokenとして使用する。 仕組みについては調べればたくさん出てくるのでそちらを参照したほうが良いかと思います。 この記事では
JWTは使うべきではない 〜 SPAにおける本当にセキュアな認証方式 〜 - Qiita
React/Redux/Spring Boot/AWSでSPAを作っているのですが 認証の方式をどうするか悩みました。 ベストと思われる認証方式をこちらに記載することにしました（随時更新します）。 JWTは使うべきじゃない ログイン済みであるという事実を サーバーサイドのセッションを使わずに保存しておく場合、 ログインした後でJWTなどのトークンをサーバーで生成し、 それをクライアントサイドで何らかの形で保存しておく必要がある。 なぜなら、ReactおよびReduxのstateで管理してしまうと、 ページをリロードされたときにstateがクリアされてしまうから。 具体的な保存先はローカルストレージくらいしか無いのだが JWTをローカルストレージに格納するのは危険。 なぜなら、ローカルストレージはJavaScriptで簡単に読み込めてしまうから。 自ドメイン以外のJavaScriptを読み込
APIファーストでバックエンドとフロントエンドを別々に開発する時にハマるクロスドメインアクセス - Qiita
いま個人で開発を行っているWebサービスがありまして、そこではバックエンドをRubyonRails、フロントエンドをClojure & ClojureScriptで開発し、APIでお互いやりとりするように設計しています。(その設計した理由は色々ありますが、単純に好きな2つの言語を使いたかったのが大きな理由の一つですw) おそらくこれからのアプリケーション開発において、このようにフロントエンドとバックエンドをサーバーも言語も分けて設計・開発することが多くなると思いますので、最近ハマった問題をシェアしておきます。 同一生成元ポリシー(Same Origin Policy) そのハマった問題というのが同一生成元ポリシーによるAjaxの規制です。 同一生成元ポリシーとは、ドメインAに配置されているHTMLファイルから別ドメインBのサーバーのAPIにAjaxで通信することが出来ないという制約です。
Fetch: クロスオリジン(Cross-Origin) リクエスト
もし任意の web サイトから fetch を行った場合、そのリクエストは恐らく失敗するでしょう。 ここで中心となる概念は オリジン – ドメイン/ポート/プロトコルの３つ揃いです。 クロスオリジンリクエスト(これらは別のドメイン(サブドメインも)、プロトコル、あるいはポートに送信されたもの)には、リモート側からの特別なヘッダが必要です。そのポリシーは “CORS” (Cross-Origin Resource Sharing) と呼ばれています。 例えば、http://example.com へのフェッチをしてみましょう。: 予想通り、fetch は失敗します。 なぜ?なぜなら、クロスオリジン制約が悪意のあるハッカーからインターネットを保護するからです。 脱線しますが、簡単に歴史的な背景を振り返りましょう。 長い間、JavaScript はネットワークリクエストを実行するための特別なメソ
同一生成元ポリシー(Same-Origin Policy) - とほほのWWW入門
同一生成元ポリシーとは オリジンとは 同一生成元ポリシーによる制約 XMLHttpRequest における制約 Canvas における制約 Iframe における制約 その他の制約 同一生成元ポリシーへの対応 同一生成元ポリシーとは クロスサイトリクエストフォージェリ(CSRF) などのセキュリティ攻撃を防止するために、ブラウザは「同一生成元ポリシー(Same-Origin Policy)」という仕組みを実装しています。「同一オリジンポリシー」とも訳されます。異なるオリジンのリソースへのアクセスに制約をかけるものです。制約はまた、JSONP や CORS(Cross-Origin Resource Sharing) と呼ばれる仕組みを利用することで一部解除することができます。 オリジンとは オリジン(Origin)は、スキーム、ホスト、ポート番号の組み合わせです。下記は同じオリジンとみなさ
包括的にSame-Origin Policy（同一生成元ポリシー）を理解する＜2021年版＞ - Qiita
記事の目的と想定読者 World Wide Webが世の中で比較的広く使われるようになって、すでに20年を超えました。アクセス元の主役もPCからスマートフォンになり、Webはシンプルを追求する設計思想から大きく幅を広げてきました。この記事は、主にサイトコンテンツ開発者が安全で便利なサイトを開発するための基礎知識を身につけるために通して読んでいただくこと、あるいは深く調べるためのネタ元として役立てることを念頭に置いて書いています。冗長に感じられることも多いと思いますが、お許しください。 なぜSame-Origin Policyがあるのか Same-Origin Policyって何？という話はWikipediaにお任せするとして、なぜSame-Origin Policyが必要なのかという話は根本的理解に必要不可欠なので、今さら感はありますが、ちゃんと書いておきます。 そもそもWorld Wid
Pythonの知っておくと良い細かい処理速度の違い8個 - kumilog.net
はじめに 標準入力 input と sys.stdin.readline ソート sort と sorted ソートの key ループ for と while リスト リストの初期化 二次元配列の場合 リストの値参照 リストへの値追加 それぞれの処理速度 まとめ はじめに 最近、PythonでAtCoderなどの競技プログラミングに挑戦しています。これまであまりに気にしなかったけど、ちょっとした書き方で処理速度が変わってくることに気づいたので、これを気に少し調べてみました。 目次にあるように、標準入力、ソート、ループ、リストについて、計8個の処理の速度比較を行いました。処理速度の計測方法は、Mac Book Pro*1を使い、timeitでそれぞれ100回計測*2し、平均と標準偏差を求めています。 結果だけ知りたい方は、まとめへどうぞ。 計測に用いたコードは以下にあります。 github.
Pythonプログラムが遅い！高速化したい！そんな時は... - Qiita
Pythonで実装したときに、処理時間が長すぎて要件を満たせないことがあります。そんなときにはこの記事で示す4種類の対策があります。 なお、高速化のために何かをすると別の何かを失います。トレードオフの代表例としては、表現の自由度、可読性、依存度、メモリ使用量、CPU使用量でしょうか。用法・容量を守って正しくお使いください。 また、高速化をする前にはスクリプトのどこが遅いのか、プロファイリングツールなどを使って確かめる必要があります。遅くない処理を頑張って高速化しても、全体の実行時間にはほとんど影響を与えません。この記事ではその手順については説明しません。 4種類の高速化手法 この記事では、下記の4種類の高速化手法について紹介します。 言語仕様・標準ライブラリの範疇でスクリプトを書き直す ライブラリを使う ライブラリを作る バイトコードを最適化する 1. 言語仕様・標準ライブラリの範疇でスク
Pythonistaなら知っておきたい計算量のはなし - Qiita
最近久しぶりにアルゴリズムイントロダクションを読んでいるのですが、ふと「Python(CPython)のデータ構造に関する各操作の計算量ってどれくらいなのかな？」と気になったので調べてみました。以下のページを参考にしています: Python Time Complexity 以下では $n$ や $k$ といった記号を使います。ここで $n$ はコンテナ内の要素数、$k$ はパラメータ内の要素数かパラメータの値とします。では見ていきましょう。 2021/05/02 コメントでのご指摘を記事に反映しました。ありがとうございます。 リスト まずはリストです。Pythonではリストは内部的にはC言語の配列として表しているようです。そのため、先頭要素の追加や削除を行うとそれ以降の要素をすべて移動する必要があるため大きなコストがかかります。なので先頭に要素を追加したり削除する必要がある場合は、代わりに
ブラウザで(WebUSBもActiveXも使わずに)FeliCaリーダーを読み込む - Qiita
他の投稿はこちら Webアプリの限界を超える方法 Webアプリの限界を超える方法(セキュリティ編) ブラウザでブラウザを操作してスクレイピングを行う Webブラウザでシリアル通信を行う ブラウザでICカードを読み込む場合、IEでActiveXを使用し、FeliCaリーダーに接続する方法が一般的です。 また最近では、WebUSBでFeliCaリーダーに接続する方法も出てきました。 今回は、WebUSBもActiveXも使用せずに、ブラウザからFeliCaリーダーに接続する方法を紹介します。 概要 構成は以下の通りです。 FeliCaリーダーを読み込むネイティブアプリを作成する ネイティブアプリ上でWebSocketサーバーを立ち上げる ブラウザからネイティブアプリのWebSocketサーバーにローカルホスト接続する ネイティブアプリでFeliCaリーダーからICカードを読み込み、WebSoc
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
