少し早いですが、メリークリスマス！事業開発部の早川です。 早いもので、入社して 1 ヶ月半が経ちました。 現在は、 prismatix の理解を深めながら、導入支援を行っています。 今回はその中から、認証 / 認可についてお伝えします。 と言っても、これまでに同僚達が書いた分かりやすい記事がありますので、これらのガイダンスの形で、整理していきたいと思います。 ジョインしました 以来、初めての記事となりますﾄﾞｷﾄﾞｷ 目標 本記事をご覧いただいた後、こちらのスライドを何となく理解できる気がすることを目標とします。 本スライドに関するブログ記事はこちらです。 AWS Dev Day Tokyo 2018 で「マイクロサービス時代の認証と認可」の話をしてきた #AWSDevDay 目的 まず、認証 / 認可を学ぶ理由を考えてみました。 近年、様々なサービスが API を通じてつながり、より便利
はじめに Webシステムの開発に携わりたくて転職して9か月，知らない事ばかりで日々勉強しております。 自分の勉強用メモとして知っておくべき技術をまとめようと思いました。 (こちらの記事にインスパイアされたものです) 技術用語について，なるべく2～3行で概要を説明できる事を目指しています。 情報が多過ぎるので，主流な技術は見出しを赤字にしています。(主観強め) また，今後需要が増えそうな技術は青字にしています。(かなり主観強め) とはいえ，新しい技術が登場すれば，数年でトレンドが変わってしまう事も多々あると思います。 ほとんどはあくまでも初心者がネットで情報をかき集めた程度のものです。 誤りがあればご指摘，ご意見など頂きたいです。 ※2023/2/6追記 不正確・不十分だと思った記載はひっそりと随時修正しています。 また，「そういえばこんなんあったな」という項目も追記しています。 あと，自分
【Golang】で【Amazon API Gateway Lambda オーソライザー】と【FirebaseAuth】を利用しての認証をやってみた - カミナシ エンジニアブログ
初めに 初めまして。2021年3月より株式会社カミナシにジョインすることとなりました、エンジニアの@Takuと申します。 業務とは直接関係ないのですが、API Gateway Lambda オーソライザーとFirebaseAuthを組み合わせた認証をやってみたので記載させていただきます。 概要 以下のチュートリアルを元に Amazon API Gateway Lambda オーソライザーを利用した認証機能を作成しました。 docs.aws.amazon.com Amazon API Gateway Lambda オーソライザーを利用することで、 認証・認可部分をAPI Gateway側で共通化できるため、 マイクロサービス化(認証・認可と業務の責務分け) サービスを提供するサーバーの負荷軽減 などのメリットが見込めるのではと考えております。 その際チュートリアルから変更した点として、 OA
REST API Common Spec としての HTTP Status Code と Error の提案 - Affamative Way
この記事は Timee Advent Calendar 2023 シリーズ 2 の14日目の記事です。 qiita.com はじめに TL;DR API HTTP Response Code Definition 2xx 4xx 5xx Errors Problem Details まとめ We’re Hiring! はじめに CTO室に10月に入社した id:cos31 です。 色々とやり始めたばかりで、ネタに苦しいので仕事にもタイミーには全く関係のないネタになります！*1 TL;DR RFC 9457 - Problem Details for HTTP APIs と RFC 9205 - Building Protocols with HTTP をあわせて使うとすっきりする インフラレイヤーとアプリレイヤー HTTP Status code が棲み分けできるステキ感 エラーメッセージ
[レベル: 上級] HTTP ステータスコードとネットワーク/DNS エラーに関する技術ドキュメントを Google は検索セントラルサイトに新規に公開しました。 この記事では、概要と、特に重要な部分を紹介します。 Google 検索での HTTP ステータスコードの扱い HTTP ステータスコードの定義は RFC 7231 などで定められています。 しかしながら、Google 検索は独自の扱いをすることもあります。 Googlebot がウェブをクロールしてきたなかで最も多く返された 20 種類のステータスコードの扱いをドキュメントは説明しています。 2xx/3xx/4xx/5xx の最終的な扱いは基本的に同じ ステータスコードは次の 4 つのカテゴリに大別できます。 200 番台 (2xx) 300 番台 (3xx) 400 番台 (4xx) 500 番台 (5xx) 基本的に、それぞ
はじめに このドキュメントは、SPA＋REST APIで構築したシステムの認証方法を、事例としてまとめたものになります。 本ドキュメントが、SPA＋REST APIにおける認証の実現方式のひとつとして、今後開発を行うシステム、プロジェクトの参考情報となることを目的としています。 なお、このドキュメントに記載しているシステムは開発中のものであり、実際に運用されているシステムではありません。その点については、ご留意のうえ、構成例としてドキュメントを参照いただければと思います。 このドキュメントは、SPA＋REST APIのシステム構成例（AWS）のアプリケーションの認証部分にフォーカスして記載したものです。 以下のような用語についての説明は、本ドキュメントでは行いません。事前に知識を持っている、もしくは必要に応じて他の資料、情報などを参照していただくことを前提とし、構築したアプリケーションと方
HTTP/1.1 200 OK Date: Sat, 22 Feb 2020 08:09:30 GMT Content-Type: application/json; charset=utf-8 Connection: keep-alive Server: nginx ETag: "e287c729017cc9785487098b6b103af6" Cache-Control: max-age=0, private, must-revalidate X-UA-Compatible: IE=Edge,chrome=1 X-Runtime: 0.003487 プロトコル：HTTP/1.1 ステータスコード：200 テキストフレーズ：OK ヘッダはさらに細分化されるが、今回は割愛。 画像引用：HTTP のメッセージ - HTTP | MDN ステータスコードは5つのクラスに分類 100番台 🧐
Amazon Web Services ブログ CloudFront Functions を使用したコンテンツの保護 AWS の高速コンテンツ配信ネットワーク（CDN）サービスである Amazon CloudFront から配信されるビデオコンテンツを保護するには、署名付き Cookieと署名付き URL の 2つの方法があります。 お客様はユースケースに応じて、どちらか一方または両方を使用することができます。 例えば HTTP Live Streaming（HLS）のセキュアなビデオ再生のために、メインマニフェスト、サブマニフェスト、トランスポートストリームセグメントを含む、全てのコンテンツに権限を与えるワイルドカード文字を持つリソース URL を承認するために、署名付き Cookie を選択することができます。 一方、クライアントが Cookie をサポートしていない、または Cook
GraphQL/REST における Authorization, Authentication について。 https://www.prisma.io/tutorials/graphql-rest-authentication-authorization-basics-ct20/ REST API Authentication (認証) Authentication には JWT を利用する。JWT を生成するコードは、以下のようになる。読み込み権限を与えることを示す "read-post" を claim として保持させ、暗号化には HS256 を利用し、この暗号化時のシークレットキーとして "secret" という文字列を利用する。 code:js import * as jwt from "jsonwebtoken"; const token = jwt.sign({ claims:
週刊Railsウォッチ: Ruby 3.1にYJITマージのプロポーザル、Rubyのmagic historyメソッド、JSのPartytownほか（20211012後編）｜TechRacho by BPS株式会社
週刊Railsウォッチについて 各記事冒頭には🔗でパーマリンクを置いてあります: 社内やTwitterでの議論などにどうぞ 「つっつきボイス」はRailsウォッチ公開前ドラフトを（鍋のように）社内有志でつっついたときの会話の再構成です👄 お気づきの点がありましたら@hachi8833までメンションをいただければ確認・対応いたします🙏 TechRachoではRubyやRailsなどの最新情報記事を平日に公開しています。TechRacho記事をいち早くお読みになりたい方はTwitterにて@techrachoのフォローをお願いします。また、タグやカテゴリごとにRSSフィードを購読することもできます（例:週刊Railsウォッチタグ） 🔗Ruby 🔗 YJITマージのプロポーザル（Ruby Weeklyより） Feature #18229: Proposal to merge YJIT
Invoke-WebRequestでエラーレスポンスを取得 - ROBOT PAYMENT TECH-BLOG
こんにちは。決済システムでエンジニアをやっております hoshino33 です。 今回はPowerShellのInvoke-WebRequestを実行した際に2XX系以外でHTTPステータスコードが返ってきた際にレスポンスボディが取れなかったので、その際に対応した内容になります。 はじめに 2XX系のレスポンス（レスポンスボディなし） 2XX系以外のレスポンス（レスポンスボディなし） 2XX系以外のレスポンス（レスポンスボディあり） 2XX系以外のレスポンス（レスポンスボディあり）を対応してみる SkipHttpErrorCheckについて まとめ はじめに Invoke-WebRequestを使用しつつ、curlでもどのようになるか比較しながら見てみようと思います。 Invoke-WebRequestとcurlは以下のバージョンで確認を行っています。 > $PSVersionTable
はじめに このチュートリアルでは、『証明書に紐付いたアクセストークン』を活用して Amazon API Gateway 上に構築した API をこれまで以上に安全に保護する方法を紹介します。 OAuth アクセストークンが一度漏洩すると、攻撃者はそのアクセストークンをもって API にアクセスできます。従来のアクセストークンは電車の切符のようなもので、一度盗まれたら誰でも使えてしまいます。 この脆弱性はアクセストークンと同時にアクセストークンの正当な保有者である証拠も併せて提示することを API 呼出者に要求することで軽減することができます。その証拠は proof of possession と呼ばれ、よく PoP と短縮されます。使用時に PoP を必要とするアクセストークンは、搭乗時にパスポートの提示も併せて要求される国際線の航空券に似ています。 RFC 8705 (OAuth 2.0
この記事は サーバーサイドから外部APIを利用する場合、HTTP通信処理を書く必要がありますよね。 rubyでHTTP通信の処理を書こうと思いライブラリを検討したら、FaradayがデファクトスタンダードになりつつあるようだということでFaradayで書くことにしました。 rubyには標準ライブラリとしてNet::HTTPがありますが、rubyガチ勢は要件や好みに合わせて他のHTTP通信ライブラリ使い分けたりするらしいです。 https://blog.bearer.sh/top-ruby-http-client-gems/ Faradayはこうした各種ライブラリを共通コードで動かすラッパーとして作られたそうなのですが、 普通の使い方ならNet::HTTPで事足りる Net::HTTPは書き方が今風じゃなくてちょっと使いにくい ということでFaradayの採用例が増えるのは納得です。 API
概要 まずはじめに、私はWebサービス屋さんです。 Webサービスを提供し続ける以上、誰もが使えるものを提供するというのは自然なことであり一定の条件を満たさないと使うことができないサービスを提供するのは本意ではないと考えています。 しかしながら、多くの場合Webアクセシビリティを意識してサービスを作る場合には、デザインであったり、デザインを実装するためのマークアップであったりが意識されがちです。 そのためサーバーサイドには無縁であると感じる人も少なくはないのではないかなと私自身は考えています。実際にサーバーサイドに出来ることがどこかに明確に書かれている項目も多くはありません。 そんな中で、サーバーサイドが、Webが、どこまで現在のWebアクセシビリティに取り組むという基礎知識になっているか、またサーバーサイドエンジニアとして出来る何かがないのかということを模索していきたいと思います。 We
CA1988 – 島根大学附属図書館デジタルアーカイブのIIIF Authentication API導入 / 青柳和仁
島根大学附属図書館デジタルアーカイブのIIIF Authentication API導入 島根大学附属図書館：青柳和仁（あおやぎかずひと） デジタル画像の相互運用のための国際規格International Image Interoperability Framework（IIIF；CA1989参照）(1)が国内外のデジタルアーカイブで近年普及してきている。IIIFでは、安定版としては4種類のAPIが機能別に規定されている(2)が、IIIF Image API とIIIF Presentation APIの2つの基本APIに対応していればIIIF対応のデジタルアーカイブとして運用することができる。島根大学附属図書館デジタルアーカイブ（以下「島大アーカイブ」）(3)では、2018年1月30日にこの2つの基本API（バージョンは2.1.1）に対応したシステムとしてリニューアルしており(4)(5)
社内ポータル徘徊にさようなら！Webスクレイピングで更新自動通知 - ASKUL Engineering BLOG
こんにちは。みやまえゆたかです。 導入 当社の社内ポータルサイトはSharePointで作られています。 各種申請書類やマニュアル、規定などへのリンクが集まっていて、 その中でも、新着情報が流れてくる「掲示板」のページは「更新がないか？」1日に1~2回は見に行くようにしています。 ただ、業務や会議がたてこんでいると「掲示板」を見ることを忘れ、重要な情報を見過ごしてしまうことがありました。 「なんで新着をスマホに通知してくれないんだ！！！」 更新が有るか無いかも分からないサイトを定期的に見る作業に疲れた私は、 「ポータルサイトをWebスクレイピングして、更新があったらSlackに通知する」機能を作りました。 処理は以下のようになっています。 ポータルサイトの「掲示板」を定期的にWebスクレイピングする 更新がないかチェックする 更新があったら、記事のタ
【Prometheus+Grafana】Mastodonサーバの外形監視（HTTPレスポンスタイム等） - はんドンクラブ 運営ブログ
こんばんは。 Mastodonインスタンスの1つである「handon.club」では，昨日より外形監視を始めました。構成は，Prometheus＋Grafanaのオンプレ構成です。 今日は，今回構築した「handon.club」における外形監視の例を使って，Mastodonサーバの外形監視方法についてご紹介したいと思います。なお，日本語で設定方法を解説している記事が見つからなかったため，具体的な設定の方法についても触れたいと思います。 外形監視 本投稿でいう外形監視とは，「HTTPレスポンス」に関する統計情報（メトリクス）を指します。一般に外形監視とは，サーバのCPU利用率やディスクI/Oといった内部の情報ではなく，サーバの外部から見える範囲での情報を使った監視のことです。よくあるping監視もそのうちの1つと考えますが，今回はHTTPレスポンスに限った話をします。 Mastodonインス
100 :continue 101 :switching_protocols 102 :processing 103 :early_hints 200 :ok 201 :created 202 :accepted 203 :non_authoritative_information 204 :no_content 205 :reset_content 206 :partial_content 207 :multi_status 208 :already_reported 226 :im_used 300 :multiple_choices 301 :moved_permanently 302 :found 303 :see_other 304 :not_modified 305 :use_proxy 306 :unused 307 :temporary_redirect 308 :perm
一言にエラーといっても色々あるのでまとめてみました。 エラーの種類 エラーは、予期したエラーと予期せぬエラーの2種類に大別できます。 予期したエラー バリデーションエラー API から返ってくるレスポンスエラー クライアントエラーレスポンス（400系） サーバーエラーレスポンス（500系） 予期せぬエラー ネットワークエラーなどの通信エラー DB やサーバーがダウンしたなど バックエンドのコードのバグ フロントエンドのコードのバグ 大前提としてエラーが起こったら、ユーザーが次に行うべきアクションが分かるような何かを伝えることが最重要だと考えています。 まず予期したエラーが起こった場合について考えてみます。 バリデーションエラー フロントエンドのバリデーションエラーはユーザーの入力時にチェックし、即時でユーザーに教えてあげるのが UX 的に良いです。 フロントエンドでチェックしているから、バ
「404 Not Found」エラーは、インターネットを使用していれば誰もが一度は見たことがあるかもしれません。 この記事では、404エラー(404 not found)が何であるか、なぜ重要なのか、そしてどのように対処すればよいかを詳しく解説します。 404エラー(404 not found)とは何か？ 404エラー(404 not found)はHTTPステータスコードの一種です。 HTTPステータスコードは、ウェブサーバーからの応答の一部としてブラウザに送信され、リクエストの状態を示します。404はその中でも「ページが見つからない」ことを示すコードです。 404エラーが表示される理由として、主にURLが間違っている、ページが削除された、または別のURLに移動したために発生します。 404以外にも存在する！HTTPステータスコードについて HTTPステータスコードは、ウェブサーバーから
Shopify App のストアフロントの実装をするとき、ストアにログイン中のカスタマーからのリクエストかどうか を Shopify App で判別したいシーンがあると思います。（たとえばロイヤリティプログラムやウィッシュリストなどのログイン中のカスタマーに紐付くような機能を持つアプリケーションなど） ソーシャルPLUS の Shopify App では、ログインしているカスタマーからのリクエストを判別し、ソーシャルログインプロバイダの ID 連携機能を実現しています。 ※ ストアフロントでカスタマーに紐づくソーシャルログインプロバイダの ID 連携状態を取得して表示させている例 Shopify App のストアフロントの実装にあたり、ストアにログイン中のカスタマーからのリクエストかどうかを Shopify App が判別する機能 は Shopify から公式に提供されていません。 よって
Studying HTTP > RFC-Translations related HTTP この文書は、 R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee: Hypertext Transfer Protocol -- HTTP/1.1 (RFC 2616), June 1999. を 橋本英彦 が日本語訳した物です。 この文書の取り扱いについては、[Studying HTTP] の RFC 日本語訳を利用するにあたってに従って下さい。 Network Working Group Request for Comments: 2616 Obsoletes: 2068 Category: Standards Track R. Fielding UC Irvine J. Gett
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
よりよくわかる認証と認可 | DevelopersIO
Webシステム開発で関わる技術のまとめ(2022年に知った物) - Qiita
HTTPステータスコードをGooglebotはどのように処理するのか？ Googleが詳細に解説
SPA＋REST APIにおけるセッションを使った認証の実践例 | Fintan
HTTPステータスコード 完全に理解した - Qiita
CloudFront Functions を使用したコンテンツの保護 | Amazon Web Services
GraphQL/REST における認証/認可 - tasuwo-graphql
金融グレード Amazon API Gateway - Authlete
ちょっぴり疑り深い人のためのFaraday - Qiita
Webアクセシビリティを支えるための技術 - 気まぐれPHPerの頭の中
【Rails】APIモードで使えるHTTPステータスコードのシンボルまとめ - Qiita
Web サービスを開発するときのエラーハンドリングについて
404エラー(404 not found)とは？エラーが出る原因と対処方法を解説！ | センタード
ストアにログイン中のカスタマーからのリクエストを Shopify App でセキュアに判別する方法
ハイパーテキスト転送プロトコル -- HTTP/1.1