[TIL] Cookie Header Issue Between FE & BE
05/16/23
![[TIL] Cookie Header Issue Between FE & BE](/_next/image?url=https%3A%2F%2Fcdn.hashnode.com%2Fres%2Fhashnode%2Fimage%2Fupload%2Fv1688363409567%2Fcf951ba9-3c22-4bce-bcb9-ec57b576a8b0.png&w=3840&q=75)
๐ Issues encountered
Issue #1
After deploying the backend server, I was able to successfully connect from the frontend localhost, but I encountered an error in cookie delivery. When I logged in, the network tab's header -> set-cookie and the application tab showed that the cookies were being stored correctly. However, when making API requests that required authentication (using an auth middleware), I received a 403 error and the cookies were not being sent at all. In the developer tools, the Cookies header was completely missing for those requests.
Issue #2
Connecting a subdomain to the backend server deployed on AWS EC2.
๐ What I tried
Issue #1
1. I double-checked the CORS settings on both the frontend and backend.
// React
const instance = axios.create({
baseURL: API_URL,
withCredentials: true, // Add this line to enable sending cookies
});
- Adding
withCredentials: trueallows the browser to automatically include cookies in the request.
app.use(
cors({
origin: "http://localhost:3000",
credentials: true,
})
);
To receive cookies, set a specific origin instead of using
*, and setcredentials: true.Since the login was already working correctly, there were no issues with CORS settings.
2. Deploy the frontend and backend servers on the same domain or on domains that match each other => Same-Origin Policy related
Based on the information that it is difficult to configure cookie settings when the frontend and backend have different domains, I tried connecting the deployed frontend server to the
broccoli-market.storedomain and the backend server to theapi.broccoli-market.storesubdomain. (Connection process -> issue #2)Again, it was a domain issue. When passing cookies between the frontend and backend, we need to adhere to the Same-Origin Policy web security mechanism.
Issue #2
The frontend was running on
localhost:3000, and the backend server was using an IP address, causing a domain mismatch issue. In fact, when accessing in violation of the same-origin policy, there was a warning sign!next to the token value in the network tab'sset-cookiesection.To match the domains, I deployed the frontend as well. The frontend was deployed to S3.
As mentioned in the previous post, I set up the domain and subdomain configurations. Subdomain setup blog post
Once the domain issue was resolved, the cookie issue was naturally resolved as well. I also updated the CORS settings to use the deployed domain name.
๐ What I newly learned
- I spent a lot of time on the subdomain configuration. At first, the connection between the subdomain and
the deployment address was working fine, but it suddenly stopped working. I tried creating a subdomain directory and setting up paths in Nginx (referencing this), but it didn't work.
Additionally, while working on the server, I accidentally switched to the root directory in the SSH, and without realizing it, I ran
pm2 startthere. But then I switched back to the SSH terminal after working on something else, and since the current directory was not our repository directory, I closed the terminal and reopened the SSH connection, and ranpm2 start app.jsagain, only to encounter an error saying that port 3000 was already in use... I couldn't remember where I originally ranpm2 start. So I changed the port number and set up port forwarding, but it still didn't work, so I ended up creating a new EC2 instance... Anyway, there were a few trial and error moments.The part I missed was the proxy server configuration. I didn't specify the proxy server in Nginx to redirect to the backend deployment IP, I only specified the subdomain name. This was resolved by setting the
proxy_passpath.We had a similar cookie issue in the previous team project, but at that time, we didn't send the token as a cookie between the frontend and backend, but rather as a header, and retrieved it using
req.headers. I wasn't directly involved in solving that issue and didn't fully understand the situation. However, in this clone project, I was able to tackle the problem myself, so although there were many challenges, I learned a lot.
๐ What to learn next
- Attempt to convert from HTTP to HTTPS.
![[์ฝํ
] ๊ทธ๋ฆฌ๋ ๋ฌธ์ - ๋ฌด์ง์ ๋จน๋ฐฉ ๋ผ์ด๋ธ](/_next/image?url=https%3A%2F%2Fcdn.hashnode.com%2Fres%2Fhashnode%2Fimage%2Fupload%2Fv1712215455263%2F1ac1f35a-8862-4e42-8d0c-e2bea01e04c0.png&w=3840&q=75)
![[์ฝํ
] Bfs ํ ๋งํ](/_next/image?url=https%3A%2F%2Fcdn.hashnode.com%2Fres%2Fhashnode%2Fimage%2Fupload%2Fv1709032619170%2F70056896-c857-444b-9c99-45bfcb466806.png&w=3840&q=75)
![[์ฝํ
] Dfs ๋ฌธ์ ์ ํ - ๊ทธ๋ํ ๋ด์์ ๊ตฌ๋ถํ์ฌ ์นด์ดํธ ํ๊ธฐ](/_next/image?url=https%3A%2F%2Fcdn.hashnode.com%2Fres%2Fhashnode%2Fimage%2Fupload%2Fv1709019361383%2Fb0585d72-c808-4169-83a9-2724f312e927.png&w=3840&q=75)
![[์ฝํ
] DFS vs BFS](/_next/image?url=https%3A%2F%2Fcdn.hashnode.com%2Fres%2Fhashnode%2Fimage%2Fupload%2Fv1708971211123%2F71f9386c-6a62-43b2-a602-4d084c24d6cf.png&w=3840&q=75)
![[์ฝํ
] ์ฌํ๊ฒฝ๋ก](/_next/image?url=https%3A%2F%2Fcdn.hashnode.com%2Fres%2Fhashnode%2Fimage%2Fupload%2Fv1708971251412%2F27ce72ed-8ee7-4d13-a02f-ff4bbe50c4be.png&w=3840&q=75)