2주차때 겪은 https, cookie 이슈를 다시 도전
백엔드형님깨 얻은 조언으로 서버라는것에 대해서 다시 생각해보게됬고,
서버의구조 아키텍처구성 등등 남에게 설명할때 구체적인 구조가없으니
충고를구하기도 힘들었다는게 느껴졌다.
내가아는 내용을 남에게 조리있게 설명하지못했다.
결국 google Meet 켜서 보여드리면서했는데도
상대를 이해시키기 쉽지않았다. 왜 클라우드프론트를썻는지,
클라우드프론트가 정확히무엇을하는지, 왜 https에 그렇게 강조를하는지등 좀더 디테일한부분을 왜 그렇게했다. 라는걸 강조하지못했다.
지금생각해보면 분명 이유는 다 알고있다. 어렴풋이알고있어서 문제되는것도있지만
긴가민가하니까 괜히 아는척하기 싫은것도있는거같다.
확신이 스질 않아서. 그런거같다.
이런관점에서 아키텍쳐를 한번 짜보고 이것에대해서 팀원들과 얘기해볼 필요가 있다는것을 느꼇다.
진짜 이부분은 프론트,백 그것을 넘어서 인프라구축에 관한얘기이며
포지션에관계없이 이쪽의 지식이있다면 좋겠다라는생각이 들었다.
지금까지 뻘짓하면서 배운 aws의 내용을 정리하면
-
첫째로 s3이외에도 amplify라는 친구가있고 정적호스팅을 해준다.
-
s3에서는 쿠키를 저장시킬수없다. 대신 캐시를 이용해서 쿠키기능을 구현해준다.
-
https 연결에 관해서 클라이언트 3s,cloudFront로 구현가능하고, 서버 ec2-alb-route53으로 구현가능하다.
-
즉 서버가 클라우드 프론트로 직접 갈필요는 없었다.
-
acm에서 내려주는 ssl인증서에서 도메인은 *.xxxx.com 이런식으로 서브도메인을 와일드카드를 써서 하면 안된다(된다고 되어있는데 안된다)
-
s3에도 cors옵션을 넣어주는곳이있다.
-
iam라고해서 Identity Access Manager라고해서 접근관리를해주는친구가이쓴ㄴ데 우리는 s3를 퍼블릭하게 했지만, https를 쓰기위해 클라우드프론트를 앞단에 물린 시점에서 퍼블릭호스팅은 필요가없게된다. 그러므로 iam을 이용해서 클라우드프론트에서만 접근할수있게 할수있다. (정책도 따로 get Object를 주지않아도 클라우드프론트 셋팅할때 자동생성시킬수있으므로 정책생성기(솔찍히 조금어려움 ..) 를 사용하지않아도된다. (어렵다기보단 안외워짐)
-
쿠키가 안보인다고 쫄지말자, 보이지않는 앞단에서 클라우드프론트가 캐싱해주고있다.response에찍히고, 다음 request에 쿠키가 셋팅되어있는것으로 확인할수있다.
-
http에서도 쿠키는 크로스오리진이되긴한다, 다만 aws가 그걸 막는거같다. (그전까지는 ec2에 배포 이후 http 그리고 로컬환경에서의 리액트 와 연결했을때 쿠키를 잘 받는다.)
-
cloudFront가 aws치고는 비교적 최근? 기술인가 싶긴하다.. 레퍼런스가 적다. (향상된 쿠키,향상된url이라는 제목으로 유료화컨텐츠에 사용할만한 시스템도 있다.)
-
탄력적 IP를 쓰는이유: ec2가 재부팅됬을경우 ip에 변동이 될수있는데. 이때 클라이언트가 가리키고있던 서버의 아이피와 달라지므로 충돌이 생긴다. (근데 이게 맞나? 잘모르겟다. elb주소를 가리키고있는 특정 route53에 등록된 도메인을 주소로할텐데, ec2가 몇개일지도모르며, 언제 유동적으로 늘어났다가 줄어들지도 모르는상황에서 -> 탄력적ip는 의미가 있는가??... elb의주소를보고있으므로 클라이언트와의 컨텍이 무너지지는 않을거같다. 그래서 안썻고, 앞으로 ec2를 재부팅하지않는이상 특별한 변화를못느낄꺼같다. (껏다켜도 별이상없을꺼같다는 생각뿐이다.)
-
acm에서 도메인으로써 주는 인증서는 route53에 등록되어있어야한다. (정확한 기준은 모르겠지만, 서브도메인 *는 안먹는다. 그리고 route53에서 제공하는 네임서버와 도메인구매처와의 연결을 해줘야하고 (최대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);
});
};생각보다 헤더셋팅 해줄필요도 없엇다.. withCredentials만 잡아주면된다 (클라이언트쪽)
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("연결 완료");
});
서버쪽도 단순했다.
s3 - CORS 설정
[
{
"AllowedHeaders": [
"*"
],
"AllowedMethods": [
"GET",
"PUT",
"POST",
"DELETE"
],
"AllowedOrigins": [
"https://www.trollo.site"
],
"ExposeHeaders": []
}
]
버킷 정책의경우 클라우드프론트 생성시 iam으로 자동생성시켰음
끗
정적웹사이트 켜놧는데 꺼도될꺼같다. (어처피 클라우드프론트통해서 들어가기때문)
기본암호화 비활성화 (어쩌다가 활성화 하라는 글을 본거같아서.. 나는 비활성화했고 잘됬다)
