Docker を利用すると、ローカル環境でも本番に近い環境を構築し、テストすることが一般的です。 本記事では、フロントエンドとバックエンドを分離した Web サービスを構築し、HTTPS を用いた ローカル環境 のセットアップ方法を解説します。 環境構築の要件 1. HTTPS でアクセスするために必要なもの HTTPSでアクセスするためには、まず証明書が必要です。AWS Route 53でドメインを登録し、証明書を取得します。 ドメインの設定 フロントエンド URL: https://front.com バックエンド URL: https://back.com とする場合、両方を A レコード(IPv4) として 127.0.0.1 に登録します。
こんにちは、 @okazu_dm です。 この記事は、CookieのSameSite属性についての解説と、その中でも例外的な挙動についての解説記事です。 サードパーティCookieやCSRF対策の文脈でCookieのSameSite属性に関してはご存知の方も多いと思います。本記事でCookieの基礎から最近のブラウザ上でのSameSite属性の扱いについて触れつつ、最終的にHSTS(HTTP Strict Transport Security)のような注意点を含めて振り返るのに役立てていただければと思います。 前提条件 Cookieについて Cookieの属性について SameSite属性について SameSite属性に関する落とし穴 SameSite属性を指定しなかった場合の挙動 SameSite: Strictでも攻撃が成功するケース 例1: スキームだけ違うケース 例2: サブドメイ
まとめ https://yomu.jp/4274065979 のような https://yomu.jp/ + ISBN という URL で本の概要が見られるサービスを作った slack に貼り付けると、その場の preview で書影とタイトルが見られる https://yomu.jp/https://www.amazon.co.jp/%E3%83%8F%E3%83%83%E3%82%AB%E3%83%BC%E3%81%A8%E7%94%BB%E5%AE%B6-%E3%82%B3%E3%83%B3%E3%83%94%E3%83%A5%E3%83%BC%E3%82%BF%E6%99%82%E4%BB%A3%E3%81%AE%E5%89%B5%E9%80%A0%E8%80%85%E3%81%9F%E3%81%A1-%E3%83%9D%E3%83%BC%E3%83%AB-%E3%82%B0%E3
Intro タイトルを見て「Cookie の新しい仕様か、キャッチアップしよう」と思って開いたのなら、以降を読む必要はない。 Cookie History 2000 年に発行された Cookie の仕様である RFC 2965 では、仕様中に Set-Cookie2/Cookie2 (以下 Cookie2) という 2 つのヘッダが定義されている。しかし 2011 年に改定された現行の RFC 6265 ではそれらヘッダは deprecate されており、実際の Web でこれらのヘッダが交換される場面を、少なくとも筆者は見たことがない。存在すら知らない開発者も多いだろう。 筆者はずっと、この仕様がどのように出てきて、どうして消えていったのかが気になっていた。Web 上にも情報が少なく、「歴史上の理由で」とか分かったようなことを言ってる人がたまにいるくらいだ。四半世紀前のことなので経緯を知
「海外事情」に寄稿した文章です。許可を得てこちらに転載します(初稿)。書いたのは昨年12月なのでデータはやや古くなりましたが、「総括」なので、内容は特に問題ないと思います。御覧ください。 緒言 日本の新型コロナ対策を「総括」、すなわち総合的なパースペクティブからまとめようとしたものが過去に2つ存在する。一つは、書籍になった「新型コロナ対応/民間臨時調査会 調査・検証報告書」[1]であり、もう一つは、政府が招聘した新型コロナウイルス感染対応に関する有識者会議が出した「新型コロナウイルス感染症へのこれまでの取組を踏まえた次の感染症危機に向けた中長期的な課題について」[2]である。 しかし、前者はどちらかというと「証言集」に近く、やや厳しい言い方をすれば、「個人の感想」集であり、属人的なものだった。データ解析、ファクトの解析には乏しかった。後者については政府に依頼されて役人が突貫工事でまとめたも
Intro IETF の RFC は、いくつかの場所で同じものが公開されている。 どの URL が最適なのか、という話。 結論は www.rfc-editor.org だ。 RFC Hosting Site 例えば RFC 9110 - HTTP Semantics で言うと、以下の 4 つがある。 https://tools.ietf.org/html/rfc9110 https://datatracker.ietf.org/doc/html/rfc9110 https://www.rfc-editor.org/rfc/rfc9110.html https://httpwg.org/specs/rfc9110.html まずは、これらの違いを簡単に解説する。 tools.ietf.org IETF がホストする RFC は、tools.ietf.org だった。 RFC 2616: Hy
Fastly の導入を検討している。検討しているだけで、導入していないので、参考にならないかもしれないし、間違っているかもしれないが、メモ。 動機 Varnish を使っていて、最初は Varnish の冗長化をしたい!だった。 まあそうなるよねえ。で、Fastly!となった。 ちなみに、Varnish を使ってる理由としては、以前も Jamstack を検討する - ゆーすけべー日記 Varnish で Stale-While-Revalidate を実現する - ゆーすけべー日記 で触れたとおり、 なるべく手間手前で、なるべく少ない箇所でキャッシュしたいからである。 Fastly でできること・したいこと Fastly でできることはたくさんあるので、その中でもしたいことを列挙。リバースプロキシ、ロードバランサの機能も含むのが便利。特に、パスごとに制御できる。なので、とあるパスはキャッ
$ git push origin branch名 remote: Support for password authentication was removed on August 13, 2021. Please use a personal access token instead. remote: Please see https://github.blog/2020-12-15-token-authentication-requirements-for-git-operations/ for more information. fatal: unable to access 'https://github.com/名前/リポジトリ.git/': The requested URL returned error: 403 Please use a personal access t
スクワッド体制における留意点として、**「Spotifyは "Spotifyモデル "を使っていない [3]」**で以下のように述べられているように、単に方法論を真似るのではく、自分の組織と向き合い、学習して、進化し続けることが大切であると思います。READYFORにおいても日々、組織体制について議論し、改善を進めています。 ビジネスユニット、部門、チーム、マネージャーは、Spotifyの失敗した方法論に固執してはいけません。彼らはSptifyのモノマネよりも効果的に組織構造の役割と責任を伝えることができるのです。 あなたがSpotify Modelを見つけたのは、自分のチームをどのように構成するかをいつも考えていたからでしょう。でもここで止まってはいけません。学習を続けてください。 1-2. READYFORのスクワッド体制 READYFORの場合、どのようなスクワッド体制を敷いているか
22 Hacking Sites To Practice Your Hacking Skills �8�U Taken from: https://hackerlists.com/hacking-sites/ 22 Hacking Sites, CTFs and Wargames To Practice Your Hacking Skills InfoSec skills are in such high demand right now. As the world continues to turn everything into an app and connect even the most basic devices to the internet, the demand is only going to grow, so it’s no surprise everyone wan
AWS News Blog Announcing AWS Lambda Function URLs: Built-in HTTPS Endpoints for Single-Function Microservices Organizations are adopting microservices architectures to build resilient and scalable applications using AWS Lambda. These applications are composed of multiple serverless functions that implement the business logic. Each function is mapped to API endpoints, methods, and resources using s
マジでアカデミアの奴らの頭の中どーなってんの フツーの会社や役所勤めなら、表立ってこんなの擁護したらヤバいって直感的に理解できるもんだが。ヨシヨシするなら裏でやるよね (筑波大学人文社会系助教らしい) https://x.com/korpendine/status/1804453867536650345?s=19 お茶大の件、この時点で嬉々として炎上に参加している大学教員が誰か、みんなよく見ておくといい。もちろん潔白だった場合このネットリンチは正当化され得ないわけだが、もっと重要なのは、かりにクロだった場合でも現時点でのリンチが遡及的に正当化されるわけではないということ。 (2024/6/22) ↓ https://x.com/korpendine/status/1183356617372454912 「おまえ自身が損をするから、あまり変なことは言うな」といった気遣いで不正の告発を「たしな
同サイトはHTTPかつデータ量が軽いため、HTTPS非対応のレトロPCやゲーム機などの接続確認によく使われていた。HTTPS化でセキュリティは高まるが、レトロ機の接続確認に使えなくなることを残念がる声が出ている。 HTTPS化は、サイトをホスティングしているニフティサービス「LaCoocan」(ラクーカン)が、10月1日からHTTPSに対応したことに伴うもの。httpとhttpsのどちらでもアクセス可能な併用期間(2026年6月末まで)の後、従来の「http://」へのアクセスは、自動的に「https://」のページにリダイレクトする予定だ。 関連記事 「阿部寛のホームページ」ついにHTTPS化へ ニフティ「LaCoocan」HTTPS対応、「阿部寛でレトロPCの接続確認できなくなる」の声 「阿部寛のホームページ」をホスティングしている「LaCoocan」がHTTPS化。ということは……。
はじめに IIJでは毎年「IIJ Bootcamp」というビギナー向けのハンズオン研修を開催しています。 4年目となる今年も有志の皆様のおかげで無事開催することができました。 今年度はOverviewと呼ばれる座学が7講義、ハンズオン研修が21講義という規模で行いました。 参考:これまでのIIJ Bootcamp [IIJ Bootcamp] ハンズオン研修2021 開催報告 [IIJ Bootcamp] ハンズオン研修2020 with リモート [IIJ] 2019年度ハンズオン研修の取り組み [Bootcamp!] 研修資料は以下のページに公開されています。一部は非公開となっていますが、大半はCC BY-SAで公開しています。 ぜひ学習や研修等とご活用ください。 https://iij.github.io/bootcamp/ 今年の特徴としては、プログラミング技法として以下のハンズオ
「通知を送るだけ」なら Webhook、「対話が必要」なら Bot で実装するのが一般的に良いでしょう。なお、今回は Webhook をテーマとしますが、今後は Bot に関する記事もあげていく予定です。 ざっくり Webhook の作成方法 1. チャンネルの設定を開く 送信先のテキストチャンネルを右クリック → 「チャンネルの編集」を選択します。 2. 連携サービスから Webhook を作成 左メニューの「連携サービス」→「ウェブフックを作成」をクリックします。 3. Webhook の設定 お名前: メッセージ送信時の表示名 アバター: アイコン画像(オプション) チャンネル: メッセージ送信先 ※ 全て後から変更可能です。 4. URL をコピー https://discord.com/api/webhooks/[ID]/[TOKEN] 形式の URL が発行されます。 ※ この
近年はChatGPTやBardなどの対話型AIが相次いでリリースされ、人間の質問や呼びかけに対して非常に高精度な回答ができることで注目を浴びていますが、これらの対話型AIは時に真実ではないことを真実かのように話す「ハルシネーション(幻覚)」を起こすことがあります。そこで、膨大な数のAPIから適切なものを呼び出し、幻覚を大幅に減らすことができる言語モデル「Gorilla」を、アメリカ・カリフォルニア大学バークレー校とMicrosoft Researchの研究チームが公開しました。 Gorilla: Large Language Model Connected with Massive APIs https://arxiv.org/abs/2305.15334 Gorilla https://gorilla.cs.berkeley.edu/ GitHub - ShishirPatil/gori
Version 1.1.0 # Changelog All notable changes to this project will be documented in this file. The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/), and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html). ## [Unreleased] ### Added - v1.1 Brazilian Portuguese translation. - v1.1 German Translation - v1.1 Spanish translation. - v1.1 Italian
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く