🙂2022.02.25

일일 회고 23회차

할일 및 한일

• 배터리 관제 시스템 사이트 관리 페이지 구현 (90%)

• 배터리 관제 시스템 프론트엔드 토큰 전달 및 재발행 로직 구현

경험 및 배움

배터리 관제 시스템 사이트 관리 페이지 구현

오늘은 사이트 관리 페이지의 사이트 수정 및 검색 기능을 구현했다.

사이트 수정은 아래와 같이 기존 정보를 가져온 후, 정보를 수정할 수 있도록 구현했다. 사용자가 수정 버튼 클릭 시, 사이트 식별자를 통해 정보를 가져오는데 기존 사이트 상세 조회 API에는 사이트 담당자 식별자와 위도, 경도 정보를 응답하지 않았다. 그래서 백엔드를 개발하고 있는 팀원에게 API 수정을 요청한 상태이다.

사이트 수정 기능

현재는 사이트 담당자 정보가 없으므로 사이트 담당자를 변경하는 기능이 없지만, 추후에 API가 수정되면 넣을 예정이다.

사이트 검색 기능은 아래와 같이 사이트 이름과 주소로 검색이 가능하도록 구현했다.

사이트 검색 기능 (이름으로 검색)

사이트 검색 기능 (주소로 검색)

해당 기능을 구현하는데 페이징과 렌더링 관련 문제가 발생했었다.

기존에는 검색을 고려하지 않고 사이트 테이블에 페이징을 적용했었으나, 검색 기능을 구현하고 10개 이상의 사이트와 일치하는 키워드를 검색하면 페이지에서 밀려나가는 문제가 발생했었다. 그래서 다음 코드와 같이 search 라는 검색어가 입력되어 필터링된 요소들을 기준으로 페이징을 다시 적용하는 로직으로 변경했다.

...
computed: {
  filter() {
    if (this.search === '' && this.pagedSite) {
      return this.pagedSite[this.currentPage - 1]
    } else {
      const sites = this.sites.filter((data) => (data.name.toLowerCase() + data.address.toLowerCase()).includes(this.search.toLowerCase()));
      const chunk = 10;
      const totalPage = sites.length / chunk + (sites.length % chunk === 0 ? 0 : 1)
      const pages = []
      for (let page = 0; page < totalPage; page++) {
        const start = chunk * page;
        pages.push(sites.slice(start, start + chunk))
      }
      return pages[this.currentPage - 1]
    }
  }
},
...

• 새로 사이트를 추가하거나 삭제했을 경우 re-rendering을 해야하는데 pagedSite 가 변경되었음을 computed 가 판단하지 못 해서, if문에서 pagedSite 가 존재하는지 확인하도록 구현했다.

배터리 관제 시스템 프론트엔드 토큰 전달 및 재발행 로직 구현

기존 프론트엔드는 AccessToken과 RefreshToken을 쿠키로만 관리하고, API를 요청할 때 헤더 정보로 AccessToken을 전달하는 로직은 미구현 상태였다. 이처럼 구현을 해놔도 백엔드에 인증/인가 로직이 부분적으로 구현되어 있으므로 다른 기능들을 구현하고 테스트 할 수 있었다.

이 와중에 사이트 관리 페이지를 구현하다보니 회원 상세 정보 조회 API 요청이 필요해졌으나, 회원 상세 정보 조회 API를 요청하면 관리자 권한을 갖고 있거나 자신과 일치하는 회원만 조회할 수 있도록 구현되어 있기 때문에 요청이 실패하는 문제가 발생했다. 그래서 프론트에서 API 요청할 때 헤더에 AccessToken을 담아서 요청하는 로직 구현을 진행했다.

모든 API 요청에 대해 헤더의 Authorization 존재 여부를 확인하고 쿠키에 토큰이 존재 여부를 확인하는 로직이 필요하며, 모든 API 응답에 대해 토큰 만료 여부 확인 및 재발행 요청 로직이 필요하다. 그러므로 Axios에서 제공하는 Interceptors에 해당 로직을 구현하여 확인하기로 결정했다.

Interceptors | Axios Docs

Axios 공식 문서 | Interceptors

Axios의 Interceptors를 활용하여 구현한 토큰 전달 및 재발행 로직은 다음과 같다.

instance.interceptors.request.use(
  config => {
    if (process.client && !config.headers.Authorization) {
      const accessToken = Cookies.get('accessToken');
      if (!accessToken && window.location.pathname !== '/login') {
        window.location.href = '/login'
      } else {
        config.headers.Authorization = `Bearer ${accessToken}`
      }
    }
    return config
  },
  error => {
    return Promise.reject(error)
  }
)

instance.interceptors.response.use(response => {
  return response;
}, error => {
  if (error.response.data.code === 'AUTH-REQ003') {
    return refreshToken()
      .then(result => {
        const tokens = result.data.information;
        Cookies.set('accessToken', tokens.accessToken)
        Cookies.set('refreshToken', tokens.refreshToken)
        return instance.request(error.config)
      })
      .catch(_ => {
        window.location.href = '/login'
      })
  }
  return Promise.reject(error);
});

개선 및 목표

• 백엔드의 사이트 관련 API 수정 완료 시, 사이트 관리 페이지 구현 완료하기

• 현재는 프론트에서 accessToken을 쿠키로 관리하지만 LocalStorage로 관리하는 것도 고려해보기

• 토큰 재발행 로직에서 에러 코드로 재발행 필요 여부를 확인하는데 다른 방법이 없을지 조사하기