[回顧録/返信]5-6日目:awsに親しんだhttps,cookie

2週目のhttps、クッキーホットスポットに再挑戦
バックエンドのお兄さんのアドバイスで、サーバーを再考しました.
サーバのアーキテクチャ構成など、他の人に説明する際に具体的な構造はありません.
なかなか忠告が得られないような気がします.
私の知っている内容は筋道が立たずに人に説明している.
結局Google Meetを開いてみんなに見せた時
相手に理解してもらうのは難しい.どうしてクラウドフロントと書くのですか?
クラウドサービスプロバイダが何をしているのか、なぜhttpsを強調しているのかなど、より詳細な部分についてそうします.この点を強調しなかった.
今から思えば、理由ははっきりしている.まだ分からないので、問題があります.
よくわからないから知らないふりしたくない
私が確信していないからです.そうですね.
この角度からアーキテクチャを組織し、チームメンバーとこの問題について議論する必要があると思います.
本当の部分は、フロントやバックグラウンドではなく、インフラストラクチャの構築についてです.
位置に関係なく、こちらの知識さえあればいいです.
今まで学んだawsの内容を整理します.

まず、s 3のほかにamplifyという友人がいて、静的な管理を担当しています.

s 3にクッキーを格納できません.キャッシュを使用してCookie機能を実現します.

https接続については、クライアント3 s、CloudFrontで実現してもよいし、サーバec 2-alb-route 53で実現してもよい.

つまり、サーバはクラウドに直接行く必要はありません.

acmが提供するssl証明書では、ドメインは*です.xxxx.comはこのようにワイルドカードを使用することはできません(可能ですが、できません)

s 3にcorsオプションを追加するところもあります.

IamはIdentity Access Managerで、アクセス管理を担当する友人が書いたこの文章で、s 3をパブリックにしましたが、httpsを書くためにクラウドフロントで転送された場合、パブリックホスティングは必要ありません.したがってiamを使用すると、クラウドフロントからのみアクセスできます.(ポリシージェネレータはGETオブジェクトを提供する必要はなく、クラウドを設定するときにサブオブジェクトとして扱うこともできるので、ポリシーを作成するのは難しい…)使用する必要はありません.(難しいというより、暗記できない)

クッキーが見えないからといって怖がらないで、クッキーが見えない前にクラウドフロントがキャッシュしてくれています.応答が撮影されたことを確認し、次のリクエストにCookieが設定されています.

httpではクッキーもcrossoriginになりますがawsが止めるようです.(その前に、ec 2に配備された後、httpおよびローカル環境での応答に接続するとCookieが受信されます.)

CloudFrontはawsとしては最近?技術のようです...研究成果が少ない.(一部のシステムでは、強化されたCookieと強化されたurlをタイトルとし、有料コンテンツに使用できる.)

フレキシブルIPを使用する理由:EC 2が再起動すると、IPが変化する可能性があります.これは、クライアントが指すサーバのIpiとは異なり、競合します.(でもこれが正しいのか、よくわかりません.elbアドレスを指す特定ルート53に登録されているドメインをアドレスとしますが、どれだけec 2があるのか、いつ動的に増加・減少するのか分からない->フレックスipは意味があるのか・・・elbのアドレスを見ているのでクライアントとの内容が崩れないと思います.だから私はそうはしません.)書いた後、後でEC 2を再起動しないと、特別な変化は感じられません.△開けても星が出ないと思っただけです.

acmはドメインの証明書としてroute 53に登録する必要があります.(正確な基準はわかりませんが、サブドメイン*は食べません.しかも購入するドメインごとに異なり、route 53が提供するネームサーバとドメイン名購入所に接続する必要があります(最大48時間、2030分程度かかります).krのような国コードドメイン名は2030分程度で巡ることができるので、スピードが速い.

ここまで来ると、なぜawsがまだ資格を持っているのか知っているようです.

最後にawsの公式文書は友好的だ.読んでいても答えが出ます.
無条件にグーグルを信じてはいけない.公式文書は難しいですが、正解に達する確率が高いようです.

axios.defaults.withCredentials = true;
  // axios.defaults.headers.common = "Access-Control-Allow-Headers:*";
  // axios.defaults.headers.common = "Access-Control-Allow-Origin:*";
  // axios.defaults.headers.common = "Access-Control-Allow-Credentials:true";
  const getClick = () => {
    console.log("get클릭");
    axios.get("https://www.trollo.site/").then((res) => {
      console.log(res.data);
    });
  };
  const postClick = () => {
    console.log("post클릭");
    axios.post("https://www.trollo.site/cookie").then((res) => {
      console.log(res.data);
    });
  };

想像以上にタイトルを設定する必要はありません...withCrements(クライアント)をキャプチャするだけ

const express = require("express");
const cors = require("cors");
const app = express();

app.use(express.json());
app.use(
  cors({
    origin: true,
    allowedHeaders: ["get", "post", "option"],
    credentials: true,
  })
);
app.get("/", (req, res) => {
  res.send({ message: "hello world" });
});
app.post("/cookie", (req, res) => {
  res.cookie("A", `VALUEA`,{sameSite:'none',secure:true});
  res.send({ message: "cookie plz?" });
});

app.listen(80, () => {
  console.log("연결 완료");
});

サーバー側も単純です.
s 3-CORS設定

[
    {
        "AllowedHeaders": [
            "*"
        ],
        "AllowedMethods": [
            "GET",
            "PUT",
            "POST",
            "DELETE"
        ],
        "AllowedOrigins": [
            "https://www.trollo.site"
        ],
        "ExposeHeaders": []
    }
]

パケットポリシーでiamを使用してクラウドフロントエンドを作成する
にこにこ
静的サイトを開いて、オフにできるようになりました.(クラウドサービスで入ったので)
デフォルトの暗号化を無効にします(たまに記事を見て有効にしたようですが...無効にしてよかったです)