🌳 고급프로젝트: middleWare(1)

이번에 진행하는 고급 프로젝트에서는 로그인한 유저 뿐 아니라 로그인하지 않은 유저도 접속하여 내용을 볼 수 있도록 구현해야 하는 부분이 몇 있다.

• 로그인 시에는 해당 유저에 맞춤형으로 변환
• 로그인을 안할 경우 일반 페이지 보여줌

그러면 로그인을 할 때는 header에 있는 토큰을 확인 -> 로그인 id 추출 -> 사용자 정보 반영과 같은 로직으로 갈 수 있다.

하지만 로그인 하지 않은 유저가 접속했을 때는 토큰이 없기에 토큰을 확인하는 미들웨어를 통과 할 수 없다. UnauthError가 발생할 수 있기에 로그인을 진행하여 토큰이 있다면 토큰을 확인하여 유저 정보를 반환하도록, 토큰이 없다면 일반 페이지가 보이도록 optional이 필요하였다.

원래 로그인한 유저만 접근 가능한 페이지에서는

const extractToken = (req: Request): string | null => {
  const authHeader = req.headers.authorization;
  if (!authHeader || !authHeader.startsWith("Bearer ")) {
    return null;
  }
  return authHeader.split(" ")[1];
};

export const authMiddleware = async (
  req: Request,
  res: Response,
  next: NextFunction
) => {
  try {
    const token = extractToken(req);
    if (!token) {
      throw new UnauthError();
    }

    const { id } = verifyAccessToken(token);
    const user = await userService.getById(id);
    if (!user) {
      throw new UnauthError();
    }

    req.user = user;
    next();
  } catch {
    next(new UnauthError());
  }
};

이와 같이 토큰 정보가 없다면 "당신은 이 페이지에 접근할 수 없습니다. 로그인 상태를 확인해주세요" 의 의미의 error를 뱉으며 status = 401이 되어야 한다.

그러면 이제 이것을 로그인하지 않은 유저 또한도 접근하게 하려면 어떻게 해야할까?

export const optionalAuthMiddleware = async (
  req: Request,
  res: Response,
  next: NextFunction
) => {
  try {
    const token = extractToken(req);
    if (!token) {
      return next();
    }
    const { userId } = verifyAccessToken(token);
    const user = await userService.getById(userId);
    if (user) {
      req.user = user;
    }
  } catch {
  } finally {
    next();
  }
};

위와 같이 토큰이 없을 경우에는 이 미들웨어를 그냥 통과하도록 next()로 다른 로직으로 넘겨주면 된다.

하지만 위의 코드만 보았을 때 맥락은 맞지만 틀린 부분이 있었다.

1. 유저 정보 찾을시, next() 누락

만약에 로그인을 한 유저인 경우,

    const user = await userService.getById(userId);
    if (user) {
      req.user = user;
    }

유저의 정보를 가져왔지만, 미들웨어에서 가져온 정보이기에 다음 로직으로 넘겨줘야 하는데 next()가 누락되어 넘겨주지 못하고 미들웨어에 남아있는다.

2. error 미처리

해당 미들웨어에서는 try-catch문을 통해서 에러가 생기면 잡아서 전역 error 함수로 넘겨주도록 설계하였다.

  } catch {
  } finally {
    next();
  }
};

하지만 코드를 다시 보니 정작 error를 잡아줘야 하는 catch에는 next가 없어서 error를 넘겨주지 못하고 있다. 이렇게 되면

1) verifyAccessToken에서 토큰이 있지만 유효하지 않은 경우
2) 토큰은 유효하지만 userId를 통해서 유저를 찾으려고 할때 해당 유저가 데이터 베이스에 없는 경우

위와 같은 상황에서는 에어가 잇음에도 이를 무시해버리게 된다.
다음 서비스에서는 중복 에러 코드를 피하기 위해서 만약에 에러를 잡는 조건문을 넣지 않았다면 에러가 발생해도 정확한 원인 및 위치를 확인하기 힘들 것이다.

3. finally next() 중복 호출

    if (!token) {
      return next();
    }

토큰이 없을 때는 원래 해당 미들웨어를 종료하고, 다음 서비스 로직으로 넘어가는 것이 이 미들웨어의 특징이기에 여기서의 next() 무조건 위치되어야 합니다.

하지만,

  } catch {
  } finally {
    next();
  }
};

try 블록 내부가 아닌 끝인 finally에서 next가 호출된다면 어떻게 될까?
try 내부에 next가 존재하지 않고 만약 에러가 있다고 해도 catch 문 안에서는 아무것도 없어서 에러를 찾을 수 없기에 finally에서의 next()는 무조건 호출이 될 것입니다.

[예상 사고 상황]
1. 토큰이 존재하여 if(!token)을 통과
2. verfyAccessToken(token)에서 유효하지 않은 토큰으로 인한 에러 발생
3. catch에서는 아무것도 잡을 수 없음
4. finally 블록으로 와서 next() 호출
5. optionalAuthMiddleware 함수 종료 -> next() 호출

만약에 이 미들웨어 다음에 또 다른 미들웨어나 라우트 핸들러가 next()를 호출하는 로직을 가지고 있다면,
next()가 한 요청에 대해 두 번 이상 호출될 수 있다. 혹은 라우트에서 클라이언트로 정보를 보낸다면 res.status.send 이러한 상황에서는 아래와 같은 error 메시지를 마주할 수 있다.

Cannot set headers after they are sent to the client 오류
-> 이미 클라이언트에게는 응답이 전송되었지만 다시 응답을 보내려고 시도할 때 발생하는 에러

이외에도 요청 처리 흐름이 꼬여서 의도치 않은 미들웨어가 실행되거나, 데이터베이스 작업이 중복으로 발생하거나 서버가 불안정해질 수 있다.

finally은 try안에서 실행이 되든 catch로 에러를 넘기든 실행되는 블록이기에 try 안에서 해결되어 클라이언트로 응답을 보내게 되고 -> next()가 한 번 더 실행이 된다. 이럴 경우 중복 호출로 이미 응답이 완료된 다음 또 다시 헤더를 설정하거나 응답을 보내려고 시도하게 된다.

꼭 미들웨어에서 사용할 시에는,,, catch까지만 작성 + try 안에서 return next()를 통해서 이후 불필요한 코드 실행을 막아주자!