DAY23

yejichoi·2022년 12월 1일

Algorithm study

실패율
슈퍼 게임 개발자 오렐리는 큰 고민에 빠졌다. 그녀가 만든 프랜즈 오천성이 대성공을 거뒀지만, 요즘 신규 사용자의 수가 급감한 것이다. 원인은 신규 사용자와 기존 사용자 사이에 스테이지 차이가 너무 큰 것이 문제였다.
이 문제를 어떻게 할까 고민 한 그녀는 동적으로 게임 시간을 늘려서 난이도를 조절하기로 했다. 역시 슈퍼 개발자라 대부분의 로직은 쉽게 구현했지만, 실패율을 구하는 부분에서 위기에 빠지고 말았다. 오렐리를 위해 실패율을 구하는 코드를 완성하라.
실패율은 다음과 같이 정의한다.
스테이지에 도달했으나 아직 클리어하지 못한 플레이어의 수 / 스테이지에 도달한 플레이어 수
전체 스테이지의 개수 N, 게임을 이용하는 사용자가 현재 멈춰있는 스테이지의 번호가 담긴 배열 stages가 매개변수로 주어질 때, 실패율이 높은 스테이지부터 내림차순으로 스테이지의 번호가 담겨있는 배열을 return 하도록 solution 함수를 완성하라.

function solution(N, stages) {
    // 모든 스테이지의 번호를 오름차순으로 정렬=> 쉽게 index로 접근하기 위해서 
    stages.sort((a, b) => a - b);
    
    const failArr = [] // 스테이지에 해당되는 유저 수, 실패율을 저장하는 배열
    
    for( let i = 1; i <= N; i++ ) {
        failArr.push({ //필요한거 객체에 넣기 
            stage : i, // 스테이지 번호
            users : 0, // 클리어하지 못한 유저의 수
            fail : 0 // 실패율
        })
    
    }
    console.log(failArr)
  
    let allUsers = stages.length; // 총 유저의 수를 저장
    for( let i = 0; i < stages.length; i++ ) { //인덱스가 0부터 시작하기 때문에 -1
    
        if( failArr[ stages[i] - 1 ] !== undefined ) { 
          //N 이상의 스테이지를 걸러주기 위해(i.e 6)
       //stages : 1, 2, 2, 2, 3, 3, 4, 6
       // stages : 4, 4, 4, 4, 4  
       //=> failArr[3] , stage 1, 2, 3은 이미 클리어했기 때문에 접근 필요X
          failArr[ stages[i] - 1 ].users++; 
          // 클리어하지 못한 유저의 수를 증가시켜라 
            
          
            // 현재 스테이지 번호와 다음 스테이지 번호가 다를 때
            // 현재 스테이지의 정보 참조가 끝났을 때
            if( stages[i] !== stages[i + 1] ) {
       //해당 스테이지 클리어 못한 사람이 더 이상 없을 때       
                const fail = failArr[ stages[i] - 1 ].users / allUsers;
                allUsers -= failArr[ stages[i] - 1 ].users;
       // 전체유저 - 해당 스테이지 클리어 못한 사람          
                failArr[ stages[i] - 1 ].fail = fail;
            }
        }
    }
    
    const answer = failArr.sort((a, b) => b.fail - a.fail);
  // 객체의 내림차순 접근 
    return answer.map(( el ) => {
        return el.stage
    })
}

Backend Class

Web Storage ( 브라우저 저장소 )

HTML5부터 해당 도메인과 관련된 특정 데이터를 서버가 아니라 클라이언트 웹브라우저에 저장할 수 있도록 제공하는 기능
쿠키(cookie)와 비슷한 기능이며, Web Storage의 개념은 키/값 쌍으로 데이터를 저장하고, 키를 기반으로 데이터를 조회하는 패턴
영구저장소(LocalStorage) / 임시저장소(SessionStorage)
Web Storage는 쿠키와 마찬가지로 사이트의 도메인 단위로 접근이 제한 => 데이터 보완

LocalStorage(영구저장소)

브라우저를 닫았다가 다시 열어도 계속 유지 => 저장한 데이터를 명시적으로 지우지 않는 이상 영구적으로 보관이 가능
도메인마다 별로도 LocalStorage가 생성
도메인만 같으면 전역으로 공유 가능
Windows 전역 객체의 LocalStorage라는 컬렉션을 통해 저장과 조회가 이루어짐

SessionStorage(임시저장소)

브라우저가 열려있는 한 페이지를 Reload 해도 계속 유지 => 브라우저를 닫으면 삭제
Windows 전역 객체의 SessionStorage라는 컬렉션을 통해 저장과 조회가 이루어짐
데이터의 지속성과 액세스 범위에 특수한 제한이 존재
Web Storage의 기본 보안처럼 도메인별로 별도로 생성 / 같은 사이트의 같은 도메인이라도 브라우저가 다르면 서로 다른 영역 => 브라우저 컨텍스트가 다르기 때문
브라우저 컨텍스트 : Document를 표시하는 환경 => 브라우저가 불러온 웹페이지

Web Storage 특징

1. 서버 전송이 없다.

저장된 데이터가 클라이언트에 존재할 뿐 서버로 전송 X => 네트워크 트래픽 비용 감소

2. 단순 문자열을 넘어 객체정보 저장 가능

브라우저의 지원 여부를 확인해 봐야함

3. 용량의 제한 X

4. 영구 데이터 저장 가능

쿠키는 클라이언트(브라우저) 로컬에 저장되는 키와 값이 들어있는 작은 데이터 파일
사용자 인증이 유효한 시간을 명시할 수 있으며, 유효 시간이 정해지면 브라우저가 종료되어도 인증이 유지된다는 특징
쿠키는 클라이언트의 상태 정보를 로컬에 저장했다가 참조
클라이언트에 300개까지 쿠키저장 가능, 하나의 도메인당 20개의 값만 가질 수 있음, 하나의 쿠기값은 4KB까지 저장
Response Header에 Set-Cookie 속성을 사용하면 클라이언트에 쿠키를 만들 수 있음
쿠키는 사용자가 따로 요청하지 않아도 브라우저가 Request시에 Request Header를 넣어서 자동으로 서버에 전송
따라서, 브라우저 저장소임에도 불구하고 백엔드와 긴밀히 연결되어 있어 쿠키에 있는 내용을 백엔드에서도 빼내어 볼 수 있음

Components of Cookies

이름: 각각의 쿠키를 구별하는 데 사용되는 이름
값: 쿠키의 이름과 관련된 값
유효시간: 쿠키의 유지시간
httpOnly, secure : 쿠기들을 안전하게 보관할 수 있도록 보안 강화 기능
도메인: 쿠키를 전송할 도메인
경로: 쿠키를 전송할 요청 경로

Cookies 단점

1. 4KB의 데이터 저장 제한

2. HTTP Request에 암호화 되지 않은 상태로 사용하기 때문에 보안이 취약

3. 쿠키는 모든 HTTP Request에 포함되어 있어 웹서비스 성능에 영향을 줄 수 있음

⭕️ Web Storage를 사용함으로써 극복 가능

How cookies work

클라이언트가 페이지 요청
서버에서 쿠키를 생성
HTTP 헤더에 쿠키를 포함시켜 응답
브라우저가 종료되어도 쿠키 만료 기간이 있다면 클라이언트에서 보관하고 있음
같은 요청을 할 경우 HTTP헤더에 쿠키를 함께 보냄
서버에서 쿠키를 읽어 이전 상태 정보를 변경 할 필요가 있을 때 쿠키를 업데이트하여 변경된 쿠키를 HTTP 헤더에 포함시켜 응답

Examples of Cookies

방문 사이트에서 로그인 시, "아이디와 비밀번호를 저장하시겠습니까?"
쇼핑몰의 장바구니 기능
자동로그인, 팝업에서 "오늘 더 이상 이 창을 보지 않음" 체크

1. 쿠키는 매번 서버로 전송

웹사이트에서 쿠키를 설정하면 이후 모든 웹 요청은 쿠키 정보를 포함해 서버로 전송
Web Storage는 저장된 데이터가 클라이언트에 존재할 뿐 서버로 전송X => 네트워크 트래픽 비용을 줄여줌

2. Web Storage는 단순 문자열을 넘어(스크립트) 객체정보를 저장할 수 있음

문자열 기반 데이터 외에 체계적으로 구조화된 객체를 저장할 수 있음 =>개발 편의성을 제공(단, 브라우저의 지원 여부를 확인해야함)

3. Web Storage는 용량의 제한X

쿠키는 개수와 용량에 제한이 있음 => 클라리언트에 최대 300개의 쿠키를 저장할 수 있으며, 하나의 사이트(도메인)에서는 최대 20개를 저장
하나의 쿠키값은 최대 4KB로 제한

그러나 Web Storage에는 제한X => 쿠키도 하위키를 이용하면 이러한 제한을 일부 해소할 수는 있으나, 대용량으로 쿠키를 저장할 일 X

4. Web Storage는 영구 데이터 저장 가능

쿠키는 만료일자를 지정하게 되어있어 언젠가 제거 => 만약 만료일자를 지정하지 않으면 세션쿠키가 됨

만일 영구 쿠키를 원한다면 만료일자를 굉장히 멀게 설정하여 해결 가능

Web Storage는 만료기간의 설정 X => 즉, 한 번 저장한 데이터는 영구적으로 존재

로그인 프로세스 이해(AccessToken, RefreshToken )

Refresh Token

refresh token : 로그인 요청을 하고 나서, 서버에서 토큰을 프론트에게 넘겨줄 때, 토큰을 하나 더 만들어서 넘겨줌 => 이 토큰을 리프레시 토큰이라함
access token : 기존에 발행하던 토큰

refresh token은 access token이 만료되었을 때, access token을 다시 발행하기 위한 용도로 쓸것이기 때문에 access token보다 유효기간이 길어야함

❓Access Token(JWT)를 통한 인증 방식의 문제는 해킹을 당했을 경우 보안에 취약하다는 점 => 유효기간이 짧은 토큰의 경우 그만큼 사용자는 로그인을 자주 해서 새롭게 토큰을 발급 받아야 하므로 불편함 => 그렇다고 유효기간을 늘리면 토큰을 해킹당했을 때 보안에 더 취약

📍이러한 점들을 보완하는 것이 Refresh Token

refresh token은 access token과 같은 형태의 JWT
refresh token은 처음에 로그인을 완료 했을 때 access token과 동시에 발급 => access token보다 긴 유효기간을 가지면서 access token이 만료되었을 때 새로 발급해 주는 열쇠가 됨
access token이 해킹 당하면 정보가 유출 => 하지만 유효기간을 짧게 해두면(30분 ~ 2시간) 그 기간 안에서만 사용이 가능하기 때문에 더 안전
refresh token의 유효기간이 만료되면, 사용자는 새로 로그인 해야 합니다. refresh token도 해킹될 가능성이 있기 때문에 적절한 유효기간(2주 ~ 2달) 설정이 필요

accessToken & refreshToken Authorization Process

사용자 로그인

서버에서 사용자가 입력한 ID, PW를 회원 DB에서 값을 비교(인가).

인가를 할 때 DB를 거치치 않고 Backend에서 Guard를 통해 인가 처리 시, 문제가 있으면 브라우저로 에러를 반환 시키고, 문제가 없으면 DB와 연동하여 API 처리가 이루어짐

로그인이 완료되면 accessToken(JWT), refreshToken(JWT) 을 발급

accessToken : 해당 데이터 payload를 통해 전달

refreshToken : 쿠키를 통해 전달

만료된 accessToken을 첨부하여 요청을 보냄

서버가 인가를 해보면서 토큰이 만료되었음을 확인하고 에러를 반환

accessToken 만료가 되어 인가시 에러가 반환되면 refreshToken으로 accessToken을 재발급 받는 API를 프론트에서 요청하는 것

토큰이 만료되었음을 확인하고 토큰 재발급 요청(restoreAccessToken)를 쿠키와 함께 요청을 보냄

restoreAccessToken API를 통해 새로운 토큰 재발급이 가능하기에 사용자가 로그인을 다시 해야하는 불편함을 해소
📍 refreshToken이 만료되었을 때만 사용자가 재로그인을 하면 됨

쿠키에 refreshToken을 확인해(인가) 새로운 accessToken을 발급해서 반환

재발급된 토큰과 함께 실패한 요청에 대해 재요청을 보냄

정상적으로 요청에 대한 값을 반환

📌accessToken 만료가 될 때마다 계속 과정 4~7 과정을 거칠 필요X
=> 프론트에서 accessToken의 payload를 통해 유효기간을 알 수 있으며, 프론트단에서 API 요청 전에 토큰이 만료됐다면 바로 재발급 요청을 할 수도 있음

로그인 API 확장

refreshToken을 발행하면서 cookie에 refreshToken이 잘 들어가는지 확인해 보고 토큰이 만료되었을 때의 에러를 확인

// auth.resolver.ts

import { UnprocessableEntityException } from '@nestjs/common';
import { Args, Context, Mutation, Resolver } from '@nestjs/graphql';
import { UserService } from '../users/user.service';
import * as bcrypt from 'bcrypt';
import { AuthService } from './auth.service';
import { IContext } from 'src/commons/types/context';

@Resolver()
export class AuthResolver {
  constructor(
    private readonly userService: UserService, //
    private readonly authService: AuthService,
  ) {}

  @Mutation(() => String)
  async login(
    @Args('email') email: string, //
    @Args('password') password: string,
    @Context() context: IContext, //Request와 Response, header 가져오기 
  ) {
    // 1. 로그인(이메일이 일치하는 유저를 DB에서 찾기)
    const user = await this.userService.findOne({ email });

    // 2. 일치하는 유저가 없으면?! 에러 던지기!!!
    if (!user) throw new UnprocessableEntityException('이메일이 없습니다.');

    // 3. 일치하는 유저가 있지만, 비밀번호가 틀렸다면?! 에러 던지기!!!
    const isAuth = await bcrypt.compare(password, user.password);
    if (!isAuth) throw new UnprocessableEntityException('암호가 틀렸습니다.');
		
		// 추가
    // 4. refreshToken(=JWT)을 만들어서 프론트엔드(쿠키)에 보내주기
    this.authService.setRefreshToken({ user, res: context.res });

    // 5. 일치하는 유저가 있으면?! accessToken(=JWT)을 만들어서 브라우저에 전달하기
    return this.authService.getAccessToken({ user });
  }
}

@Context() : Request와 Response, header 등에 대한 정보들이 context에 존재 => 데코레이터를 통해 해당 context 정보를 가지고 올 수 있도록 설정
setRefreshToken 비즈니스 로직을 실행해 context 안에 존재하는 res 객체의 cookie에 refreshToken 토큰을 넣어줌
refreshToken은 return을 사용해서 프론트로 보내주는 것이 아니라 요청(req)에 대한 응답(res)으로, res 안에 cookie가 들어있는 채로 프론트엔드로 보내주게됨

=> refreshToken은 cookie를 통해 받게되고 accessToken은 payload를 통해 받게됨

// auth.service.ts

//setRefreshToken 이라는 비즈니스 로직을 추가
import { Injectable } from '@nestjs/common';
import { JwtService } from '@nestjs/jwt';

@Injectable()
export class AuthService {
  constructor(
    private readonly jwtService: JwtService, //
  ) {}

	// 추가
  setRefreshToken({ user, res }) {
    const refreshToken = this.jwtService.sign(
      { email: user.email, sub: user.id },
      { secret: 'myRefreshKey', expiresIn: '2w' },
    );

    // 개발환경
    res.setHeader('Set-Cookie', `refreshToken=${refreshToken}; path=/;`);

    // 배포환경
    // res.setHeader('Access-Control-Allow-Origin', 'https://myfrontsite.com')
    // res.setHeader(
    //   'Set-Cookie',
    //   `refreshToken=${refreshToken}; path=/; domain=.mybacksite.com; SameSite=None; Secure; httpOnly;`
    // )
  }

  getAccessToken({ user }) {
    return this.jwtService.sign(
      { email: user.email, sub: user.id },
      { secret: 'myAccessKey', expiresIn: '1h' },
    );
  }
}

JwtService의 sign 메서드를 사용해 refreshToken을 발급
- 항상 refreshToken의 expire 시간은 accessToken의 expire 시간 보다 길어야 함
개발할 때는 받아온 res내 header(res.setHeader())의 cookie 부분('Set-Cookie’)에 refreshToken을 추가해줌

// app.module.ts
// ...생략
@Module({
  imports: [
    AuthModule,
    BoardModule,
    ProductModule,
    ProductCategoryModule,
    UserModule,
    GraphQLModule.forRoot<ApolloDriverConfig>({
      driver: ApolloDriver,
      autoSchemaFile: 'src/commons/graphql/schema.gql',
      context: ({ req, res }) => ({ req, res }), // ⭕️ 추가
    }), //graphql로 들어온 req와 res를 API들에서 사용할 수 있게끔 설정
    TypeOrmModule.forRoot({
      type: 'mysql',
      host: 'localhost',
      port: 3306,
      username: 'root',
      password: 'root',
      database: 'myproject',
      entities: [__dirname + '/apis/**/*.entity.*'],
      synchronize: true,
      logging: true,
    }),
  ],
})
// ...생략

Graphql을 통해서 login 요청을 해보면 실제 저장된 쿠키는 Application 탭에서 확인 가능

💡cookie에서 refreshToken 확인이 안된다면 설정 후 SAVE SETTINGS

토큰재발급API 구현 (restoreAccessToken)

accessToken이 만료

refreshToken을 통해 accessToken을 재발급 받을것이기에 먼저, refreshToken의 인가 과정을 진행

인가가 완료되면 refreshToken을 이용하여 accessToken을 재발급

만든 accessToken을 브라우저로 넘겨줌

// auth.resolver.ts

import { UnprocessableEntityException, UseGuards } from '@nestjs/common';
import { Args, Context, Mutation, Resolver } from '@nestjs/graphql';
import { UsersService } from '../users/users.service';
import * as bcrypt from 'bcrypt';
import { AuthService } from './auth.service';
import { IContext } from 'src/commons/types/context';

@Resolver()
export class AuthResolver {
  constructor(
    private readonly authService: AuthService, //
    private readonly usersService: UsersService,
  ) {}

  @Mutation(() => String)
  async login(
    @Args('email') email: string, //
    @Args('password') password: string,
    @Context() context: IContext,
  ) {
    // 1. 이메일이 일치하는 유저를 DB에서 찾기
    const user = await this.usersService.findOne({ email });

    // 2. 일치하는 유저가 없으면?! 에러 던지기!!!
    if (!user) throw new UnprocessableEntityException('이메일이 없습니다.');

    // 3. 일치하는 유저가 있지만, 비밀번호가 틀렸다면?!
    const isAuth = await bcrypt.compare(password, user.password);
    if (!isAuth) throw new UnprocessableEntityException('암호가 틀렸습니다.');

    // 4. refreshToken(=JWT)을 만들어서 프론트엔드 브라우저 쿠키에 저장해서 보내주기
    this.authService.setRefreshToken({ user, res: context.res });

    // 4. 일치하는 유저도 있고, 비밀번호도 맞았다면?!
    //    => accessToken(=JWT)을 만들어서 브라우저에 전달하기
    return this.authService.getAccessToken({ user });
  }

  @Mutation(() => String)
  restoreAccessToken(
    @Context() context: IContext, //
  ) {
    // accessToken(=JWT)을 만들어서 브라우저에 전달하기
    return this.authService.getAccessToken({ user: context.req.? });
  }
}

// common / auth / jwt-refresh.strategy.ts
// GraphQL용 refreshToken을 인가하는 Guard를 만들기 위함
import { PassportStrategy } from '@nestjs/passport';
import { Strategy } from 'passport-jwt';

export class JwtRefreshStrategy extends PassportStrategy(Strategy, 'refresh') {
 constructor() {
   super({
     jwtFromRequest: (req) => {
       const cookie = req.headers.cookie;
       const refreshToken = cookie.replace('refreshToken=', '');
       return refreshToken;
     },
     secretOrKey: 'myRefreshKey',
   });
 }
 
// 인가에 성공한다면
 validate(payload) {
   console.log(payload); // { email: c@c.com, sub: qkwefuasdij-012093sd }
   return { //사용자 정보 반환 
     email: payload.email,
     id: payload.sub,
   };
 }
}

쿠키내에 존재하는 refreshToken을 가져오는 함수를 만듦
- req의 헤더 내 cookies가 존재하고, cookie 안에 자동으로 첨부된 refreshToken만(refreshToken= 제외) 빼내어 줌
req 내 헤더의 cookies를 가져오는데 만약 존재할 경우 문자열로 반환해서 발행했던 secretOrKey를 사용해 토큰을 열어줌
인가에 성공하면 validate로 넘어가 토큰의 payload를 열어서 사용자의 정보를 반환

// common / auth / gql-auth.guard.ts
// gql에서 guard를 직접적으로 사용하지 못하기 때문에 만들어줌(중간파일)

import { ExecutionContext } from '@nestjs/common';
import { GqlExecutionContext } from '@nestjs/graphql';
import { AuthGuard } from '@nestjs/passport';

export class GqlAuthAccessGuard extends AuthGuard('access') {
  getRequest(context: ExecutionContext) {
    const ctx = GqlExecutionContext.create(context);
    return ctx.getContext().req;
  }
}

// 추가
export class GqlAuthRefreshGuard extends AuthGuard('refresh') {
  getRequest(context: ExecutionContext) {
    const ctx = GqlExecutionContext.create(context);
    return ctx.getContext().req;
  }
}


// auth.resolver.ts
//...생략
 @UseGuards(GqlAuthRefreshGuard) // 추가 
  @Mutation(() => String)
  restoreAccessToken(
    @Context() context: IContext, //
  ) {
    // accessToken(=JWT)을 만들어서 브라우저에 전달하기
    return this.authService.getAccessToken({ user: context.req.user });
  }
//현재 유저 정보인 context 내 user에 대한 accesstoken을 새로 만들어 
//authService를 사용해 새로 발행한 토큰을 다시 클라이언트(프론트)에게 응답

//auth.module.ts
//...생략
@Module({
  imports: [
    JwtModule.register({}), //
    TypeOrmModule.forFeature([User]),
  ],
  providers: [
    JwtRefreshStrategy, //추가
    AuthResolver, //
    AuthService,
    UserService,
  ],
})

HW

yejichoi

이전 포스트

DAY19

다음 포스트

DAY23

Algorithm study

Backend Class

Web Storage ( 브라우저 저장소 )

LocalStorage(영구저장소)

SessionStorage(임시저장소)

Web Storage 특징

Components of Cookies

Cookies 단점

How cookies work

Examples of Cookies

로그인 프로세스 이해(AccessToken, RefreshToken )

Refresh Token

accessToken & refreshToken Authorization Process

로그인 API 확장

토큰재발급API 구현 (restoreAccessToken)

HW

DAY19

DAY25

0개의 댓글

DAY23

Algorithm study

Backend Class

Web Storage ( 브라우저 저장소 )

LocalStorage(영구저장소)

SessionStorage(임시저장소)

Web Storage 특징

Cookie

Components of Cookies

Cookies 단점

How cookies work

Examples of Cookies

Web Storage VS Cookie

로그인 프로세스 이해(AccessToken, RefreshToken )

Refresh Token

accessToken & refreshToken Authorization Process

로그인 API 확장

login ( + JWT기반 refreshToken 쿠키에 저장 )

토큰재발급API 구현 (restoreAccessToken)

HW

DAY19

DAY25

0개의 댓글