728x90
CASL이란?
- 특정 클라이언트가 엑세스 할 수 있는 리소스를 제한하는 동형 인증 자바스크립트 라이브러리임. CASL은 속성 기반 엑세스 제어를 구현한다.
CASL은 npm i @casl/ability 로 설치가 가능함
이건 소리인지 잘 모르겠는데 중요할 것 같아서 긁어왔음
개발 빌드
중요 : GitHub /dist폴더의 빌드 파일은 릴리스 중에 체크인되지 않습니다. GitHub의 최신 소스 코드에서 CASL을 사용하려면 직접 빌드해야 합니다! 프로젝트 루트를 탐색하고 다음을 실행합니다.
git clone git@github.com:stalniy/casl.git
cd casl
pnpm i -rcd packages/casl-ability
npm run build
CASL은 쉽게 사용자의 역할에 따라 액세스 할 수 있는 권한을 확실하게 부여해서 허튼 짓을 못하게 하는 안전장치인 것 같음.
하지만.... NoSQL을 지원하는 것 같기 때문에 우리는 사용하지 않을 것 같음
내가 맡은 Schedule 파트에 대한 엔티티 작성을 컨펌 받고 수정해본 것.
import { Column, CreateDateColumn, Entity, JoinColumn, ManyToMany, ManyToOne, OneToMany, PrimaryGeneratedColumn, UpdateDateColumn } from "typeorm";
import { Group } from "src/groups/entities/group.entity";
import { ScheduleMember } from "src/schedule-members/entities/schedule-member.entity";
import { Users } from "src/users/entities/user.entity";
@Entity({
// Entity 설정 시 이름을 주지 않으면 테이블을 생성할 때 이름이 없음...
name: 'schedules'
})
export class Schedule {
@PrimaryGeneratedColumn()
scheduleId: number;
@Column({type:'', nullable:false})
category: // enum값
@Column({type: 'varchar', nullable:false})
title:string;
@Column({type:'text', nullable:false})
content: string;
// 생각해보니까 스케쥴 날짜는 필수적으로 있어야함 true -> false로 수정
@Column({type:'date', nullable: false})
scheduleDate: Date;
// createdAt nullable 옵션 제거
@CreateDateColumn({type: 'timestamp'})
createdAt: Date;
// updatedAt nullable 옵션 제거
@UpdateDateColumn({type: 'timestamp'})
updatedAt: Date;
/** 1개의 스케쥴에 참여하는 여러명의 멤버가 있음 **/
@OneToMany(() => ScheduleMembers, (scheduleMembers)=> scheduleMember.schedule)
scheduleMembers: ScheduleMembers[]
/** 1명의 유저는 여러개의 스케쥴을 가질 수 있음**/
@ManyToOne(() => Users, (users) => users.schedule, {onDelete: 'CASCADE'})
@JoinColumn({name: 'userId', referencedColumnName: 'userId'})
users: Users;
@Column({type:'int', nullable:false})
userId: number;
/** Group의 groupId와 관계가 맺어져있음 삭제할 때 같이 사라지게함**/
@ManyToOne (() => Groups, (groups) => groups.schedule, {onDelete: 'CASCADE'})
@JoinColumn({name: 'groupId', referencedColumnName:'groupId'})
groups:Groups;
@Column({type: 'int', nullable:false})
groupId: number;
}
-------------------------------------------------------------
@Column({type:'enum',enum: Category, nullable:false})
category: Category
enum 사용할 때 type, enum 둘다 타입 지정해줘야함casl에 대해 생각해보기
- CASL: JS 어플리케이션에서 복잡한 권한 관리를 도와주는 라이브러리 사용자 역할과 권한을 정의하고 해당 권한을 어플리케이션 전체에 적용하는 유연하고 강력한 방법을 제공함. 여러 사용자가 다른 측면에서 작업하는 경우 작업을 수행하기 위해 필요한 데이터에 적절한 액세스 수준이 있는지 확인해야함(권한이 있는가?)
간단하게 생각하기
- 회원, 비회원, 그룹 멤버 3가지 역할에 대한 액세스 권한이 있기 때문에 서비스가 확장이 되어도 역할에는 큰 변동이 없을 것 같기 때문에 굳이 적용하지 않아도 괜찮을 것 같음.(역할이 적기 때문에 필요 없다.)
- 근데… 확실한 역할 제한을 통해 안전 장치를 만들어 줄 수 있을 것 같음.
db무엇을 쓸 것 인지(일단 SQL로 간다.)
jwt와 session
세션과 쿠키라는 기술을 사용하는 이유?
- HTTP 프로토콜은 클라이언트와 서버의 통신이 끝나면 바로 상태 정보를 잊어버린다. 이러한 문제를 해결하기 위해 세션과 쿠키를 사용한다.
로그인 과정
- 세션: 서버 메모리에 생성되는 저장 공간 세션에 로그인한 유저의 정보가 저장이 되고, 세션에 저장된 정보에는 고유의 세션id가 부여된다. 유저가 로그인을 하면 서버가 쿠키에 세션id를 실어서 브라우저에 보냄 브라우저는 쿠키 저장소에 쿠키를 보관하고, 해당 유저의 쿠키가 필요할 때 마다 요청 헤더에 포함해서 전송한다. ** 로그인이 계속 유지되는 이유는 페이지가 이동할 때 마다 쿠키를 요청 헤더에 포함해서 전송하기 때문임.
세션과 쿠키 방식의 문제점
- 저장 공간 용량
- 서버 메모리에 저장이 되기 때문에 유저가 많으면 많을 수록 서버 메모리에 저장해야하는 세션이 늘어나기 때문에 메모리에 과부하가 걸릴 수 있음.
- 확장성 문제
- 세션은 서버 메모리에 저장이 되기 때문에 서버를 확장하거나 분산시킬 경우 세션 분산 기술을 따로 설계해야한다.
세션과 쿠키의 대체제 JWT(Json Web Token)
- JWT HADER: 토큰의 종류, Signature 생성을 위해 어떤 알고리즘을 사용했는지를 담고있음
- JWT PAYLOAD: 로그인한 사용자를 증명할 수 있는 기본적인 정보를 담음. 클라이언트가 다시 토큰을 보내면 해독을 해서 DB 내부의 유저정보와 비교를한다.
- JWT SIGNATURE: 토큰을 인코딩하거나 유효성 검증을 할 때 사용하는 고유한 암호화 코드임.(제 3자에 의해 토큰이 탈취되면 페이로드의 내용이 변경된다면 토큰 값이 크게 변경됨)
LocalStorage / WebStorage / SessionStorage
- WebStorage: 서버가 아닌 클라이언트 내에서 데이터를 저장할 수 있다록 지원하는 저장소, 쿠키의 단점을 보완하기 위해서 HTML5에서 추가된 ‘로컬 스토리지 / 세션 스토리지’
서버에 저장이 되지 않음 중요성이 낮거나 유실되어도 무방한 데이터를 저장하는 것이 좋음 - LocalStorage: 만료기간이 존재하지 않고 페이지를 변경하거나 브라우저를 닫아도 반 영구적으로 유지되는 저장소 직접 스토리지를 초기화, 제거를 하지 않는 이상 만료기간이 없다. 페이지를 변경하거나 닫아도 값이 유지된다. 도메인이 다를 경우 로컬 스토리지 공유는 불가능함.
- SessionStorage: 브라우저 탭 안에 유효한 저장소, 브라우저를 닫는 경우 소멸이 되는 저장소임. 브라우저 탭 안에서만 유효한 저장소. 브라우저가 다른 경우 해당 저장소 값이 유효하지 않음.
같은 도메인이어도 세션(서버 메모리 안의 공간)이 다르면 접근이 불가능
** 세선(Session)
- 일정 시간 동안 같은 사용자(브라우저)로부터 들어오는 일련의 요청을 하나의 상태로 보고 그 상태를 유지하는 기술 세션은 쿠키 기반이지만 서버 측에서 관리함.(쿠키: 사용자 정보 파일을 브라우저에 저장함)
- 서버에서는 클라이언트 구분을 위해 세션 ID를 부여하고, 웹 브라우저가 서버에 접속해서 브라우저를 종료할 때 까지 인증 상태를 유지함
JWT의 장점
- 세션과 쿠키와 다르게 서버 메모리 저장 공간을 확보할 필요가 없음.