인증/보안 세션에서 session을 접하였기에 당연히 session이 인증/보안을 위해 생겨난 무엇이라고 생각을 했다.
하지만 세션은 인증/보안의 역할을 하기 이전에 브라우저가 서버에 어떠한 요청을 했을때
이 요청을 어떤 브라우저가 보낸 것인지 식별하기 위해 서버에서 생성되는 기본 객체였다.
(브라우저에서 최초로 서버에 요청을 보내면 서버쪽에서 브라우저를 식별할 수 있도록 세션이라는 기본 객체를 만든다.
그 기본 객체안에는 세션ID가 있고 이 세션ID를 쿠키에 담아서 브라우저로 보내주면
브라우저는 앞으로의 모든 요청에 세션ID를 서버에 보낸다.
서버는 요청에 포함된 쿠키의 세션ID를 통해 어떤 브라우저인지 식별할 수 있게 된다.)
세션이 브라우저마다 하나씩 만들어지는 그리고 서버에 저장되는 특성을 활용해서
로그인 관련한 중요한 정보 및 클라이언트에 보관하면 민감한 정보들을
세션에 저장하여 인증/보안의 역할을 할 수 있게 하는 것이다.
출처 : https://youtu.be/VrWK1VPW5Qg
위의 과정을 아래의 그림으로 표현해 보았다.
위 그림의 3을 보면 PW를 해싱한 값과 DB를 비교해서 로그인에 성공한다면 세션을 생성하고
response의 cookie에 sessionID를 보내줌이라고 적혀있는 부분을 확인할 수 있다.
하지만 코드스테이츠에서의 session sprint에서 로그인 요청을 받고 응답을 보내줄때에는
3의 과정이 없어도 test case를 통과함은 물론이거니와 sprint이후 제공된 reference에도 3의 과정이 보이지 않았다.
(세션 객체에 userId를 저장하는 부분은 있었지만... 쿠키에 sessionID를 보내는 부분이 없다.)
const { Users } = require('../../models');
module.exports = {
post: async (req, res) => {
// userInfo는 유저정보가 데이터베이스에 존재하고, 완벽히 일치하는 경우에만 데이터가 존재합니다.
// 만약 userInfo가 NULL 혹은 빈 객체라면 전달받은 유저정보가 데이터베이스에 존재하는지 확인해 보세요
const userInfo = await Users.findOne({
where: { userId: req.body.userId, password: req.body.password },
});
// TODO: userInfo 결과 존재 여부에 따라 응답을 구현하세요.
// 결과가 존재하는 경우 세션 객체에 userId가 저장되어야 합니다.
if (!userInfo) {
// your code here
res.status(400).send({ data: null, message: 'not authorized' });
} else {
req.session.save(function (err) {
req.session.userId = `${userInfo.userId}`;
res.status(200).send({ data: userInfo, message: 'ok' });
});
}
},
};
여기서부터 뭔가 잘못됬다라고 생각을 하였고 ... 답을 찾아나섰다.
답을 찾아나서면서 참고한 링크는 아래와 같다.
https://stackoverflow.com/questions/16919051/how-can-i-get-sessionid-from-a-request?rq=1
브라우저(클라이언트)에 sessionID를 보내준다고 적었으나,
실제로 client에서는 connect.sid라는 고유값만을 받게 된다.
connect.sid는 서버에서 지정한 secret(salt)과 sessionID를 암호화하여 만들어진 것이다.
또한 쿠키에 connect.sid를 보내주는 등의 내가 고민했던 부분은
middleware에 의해 자동으로 처리되기 때문에
직접 쿠키에 접근하거나 할 필요가 없다라는게 깊은 탐구의 결론이다.
혼자서 이것저것 찾아보며 내린 결론으로 오류가 있을 수 있습니다. 알려주시면 더 공부하여 수정하도록 하겠습니다.
'코드스테이츠' 카테고리의 다른 글
2021년 7월 9일 코드스테이츠 DAY-96 Docker (2) | 2021.07.09 |
---|---|
2021년 7월 7일 코드스테이츠 DAY-94 Token Based Authorization (0) | 2021.07.07 |
2021년 7월 5일 코드스테이츠 DAY-92 HTTPS, 쿠키, 세션, 캐시 (0) | 2021.07.05 |
2021년 7월 2일 코드스테이츠 DAY-89 mysql(CRUD), DB 테이블 관계 (0) | 2021.07.02 |
2021년 6월 30일 코드스테이츠 DAY-87 인증/보안 기초 sprint review (0) | 2021.06.30 |