[B! HTTPS][Qiita] asa_ca3のブックマーク

asa_ca3 id:asa_ca3

HTTPSとQiitaに関するasa_ca3のブックマーク (2)

SPAのログイン認証のベストプラクティスがわからなかったのでわりと網羅的に研究してみた〜JWT or Session どっち？〜 - Qiita
SPAのログイン認証のベストプラクティスがわからなかったのでわりと網羅的に研究してみた〜JWT or Session どっち？〜JavaScript RailsJWT認証React SPAのログイン周りについて、「これがベストプラクティスだ！」という情報があまり見当たらないので、様々な可能性を模索してみました。いろいろな状況が想定され、今回記載する内容に考慮の漏れや不備などがありましたら是非コメントでご指摘いただきたいです！特に「おすすめ度：○」と記載しているものに対しての批判をどしどしお待ちしております！この記事でおすすめしているものであっても、ご自身の責任で十分な検討・検証の上で選択されてください。前提想定しているAPIは、ログイン外のAPIにはPOST/PUT/DELETEのものがなく、GETのみ GETのAPIにはDBを更新するなどの操作がないとし、そのためログイン外では
asa_ca3 2020/04/27
session 出てきた。。

ログイン

認証

HTTPS

Cookie

Qiita

SPA
リンク
CORSまとめ - Qiita
今更ですが、CORS (Cross-Origin Resource Sharing)を色々試していたら、思っていた以上に色々パターンがあることに気づいたので、改めてその扱い方についてまとめてみました。そもそも現在のWebブラウザでは、あるWebサイトが持つ情報が別の悪意あるWebサイトに悪用されるのを防ぐために、Same-Origin Policy(日本語では同一生成元ポリシー)が適用されます。例えば、あるWebサイト https://guiltysite.com をブラウザで表示している時に、このWebページからXMLHttpRequest(以下、XHR)やFetch APIで別のWebサイト https://innocentsite.net からHTTP(S)でデータを読み込もうとすると、エラーになる、というわけです。しかし、アクセス元が悪意あるWebサイトならともかく、データ
asa_ca3 2019/03/14
“Access-Control-Expose-Headers”

HTTPS

Qiita

CORS

api
リンク
1