분류 전체보기

jsonwebtoken이라는 라이브러리를 통해 node에서 jwt를 구현할 수 있다. npm i jsonwebtoken jwtMaker const jwt = require('jsonwebtoken'); const jwtMaker = (id) => { const payload = { id: id }; const secret = process.env.SECRET; const options = { expiresIn: '15m', }; const token = jwt.sign(payload, secret, options); return token; }; module.exports = jwtMaker; expiresIn을 통해 토큰의 만료시간을 설정해주었고, payload로 user_id를 기입해주었다. user..

왜 이런짓을 하는거지? 유저가 로그인을 하면, 인증이 된다. 근데 그 뒤에는? 클라이언트가 페이지를 이동하면? 어떻게 그 인증정보를 유지할 수 있을까? HTTP요청은 Stateless이다. 즉, 이전 통신 내용을 기억하지 못한다. 그래서 100번 통신을 하면 100번 모두 0422임을 증명해줘야 한다. 그럼 100번 통신하면 100번 다 로그인할꺼냐? 그건 좀 아닌 것 같다. 이를 위한 방법으로는 세가지가 있는데 쿠키만사용, 세션/쿠키, JWT가 있다. 쿠키 사용자가 로그인을 하면 서버에서는 사용자 정보를 담은 쿠키를 생성해서 응답값으로 던져준다. 클라이언트는 이를 받아서 브라우저 쿠키형태로 저장을 해두고, 요청시마다 header에 담아서 서버로 날려준다. 근데인증을 위해서는 계정정보를 쿠키에 담고 있어..

보안 회원가입시에 pw를 받는데 이걸 DB에 그냥 저장해서는 안된다. 그래서 이를 해시하여 저장을 한다. 이러면 DB가 해킹을 당한다고 해도 원문 비밀번호를 모르므로 인증, 인가에 문제가 생길 확률이 낮아지게 된다. 하지만 해시 함수의 특성상 1이라는 값을 넣으면 항상 고정된 값이 나오므로 이걸 저장한 레인보우 테이블이라는게 존재한다. 예를들어 비밀번호가 'password'라면, 이걸 그냥 해시하게되면 항상 sdkflknut23h17이라는 값이나오게 된다. 항상 sdkflknut23h17이기 때문에 결국 sdkflknut23h17을 보면 password라고 유추해낼 수 있게 되는 것이다. salt 이런 문제를 해결하기 위해 회원가입시에 랜덤한 문자열 값인 salt를 입력으로 들어온 pw에 덧붙여서 해시하..

express 구성 routes라는 폴더를 만들고 라우터를 연결해주었다. const express = require('express'); const cors = require('cors'); const morgan = require('morgan'); const dotenv = require('dotenv'); const app = express(); dotenv.config(); app.set('port', 8080); app.use( cors({ origin: '*', }) ); app.use(morgan('dev')); app.use(express.json()); app.use(express.urlencoded({ extended: true })); app.listen(app.get('port'),..

간단 메모, 필기 nodemon 서버코드에 수정사항 생길때 마다 서버를 자동으로 제시작해줌 const express = require('express'); const app = express(); app.set('port', 3000); app.get('/', (req, res) => { res.send('Hello Express'); }); app.listen(app.get('port'), () => { console.log(app.get('port'), '번 포트로 서버 열림'); }); app.set을 통해 서버가 실행될 포트를 지정함 app.get(주소, 라우터)에 대해 주소에 대한 GET요청이 왔을때 어떤 동작을 할 지 적음 요청에 따라 프로토타입 메서드로 post,put,patch,delete..

REST REpresentational State Transfer ⇒ 서버의 자원을 정의하고 자원에 대한 주소를 지정하는 방법을 가리킴 여기서 자원이란, 서버가 행할 수 있는 것들을 통틀어서 의미함 주소는 명사로 구성함 주소로는 어떤 동작을 할 것인지 명확하지 않으므로, HTTP요청 메서드를 사용함 GET 서버 자원을 가져오고자 할때 사용함 POST본문에 등록할 데이터를 넣어 보냄 서버에 자원을 새로 등록하고자 할때 사용함 PUT 서버 자원을 요청 데이터로 치환할 때 DELETE 서버 자원을 삭제할 때 OPTIONS 요청을 하기전에 통신 옵션을 설명하기 위해 사용함

생애주기 카테고리 1. 마운트 2. 업데이트 3. 언마운트 라이프사이클 메서드 총 9개의 메서드로 구성 Will : 어떤 작업을 하기 전에 실행되는 메서드 Did : 어떤 작업을 완료한 후에 실행되는 메서드 마운트 Dom이 생성되고, 웹브라우저상에 처음 나타나는 것 과정 컴포넌트 생성 constructor 실행 getDerivedStateFromProps 부모로 부터 받은 props를 자신이 가진 state에 넣을때 사용하는 메서드 render componentDidMount 업데이팅 업데이팅은 다음의 네 경우에서 일어남 props가 바뀔때 state가 바뀔때 부모 컴포넌트가 리렌더링될때 this.forceUpdate로 강제 렌더링을 트리거할때 과정 업데이트 trigger getDerivedStateFr..

https://cauisscheduler.netlify.app/ 졸업 학점 계산기 cauisscheduler.netlify.app 배포, 광고삽입, 피드백받기까지 처음 해본 개인프로젝트이다. 시작은 그냥 내 학점 얼마남았는지 포탈에서 보기 너무 어려워서 시작했다. 배포 맨날 aws와 씨름하다 netlify로 배포하니까 그냥 고민할게 하나도 없었다. 심지어 백엔드도 없는 단독서비스라 그냥 push만 하면 1분내로 배포가 되서 너무 심플하니 좋았다. 구글 애널리틱스와 피드백 GA를 달면 내 서비스가 어느 시즌에 잘 먹히는지 확인할 수 있다. 아쉽게도 에타에 올린 달(+수강신청 장바구니시즌)까지만 조금 인기였고, 이후에는 인기가 별로 없었다. 아무래도 학과 + 특정 융합전공 특화였기때문에 쓸사람은 이미 다썼다..

프로젝트에 소셜로그인을 구현했다. 로컬에서 테스트를 하고, 배포에서 실제 사용해야하니 로컬환경과 배포환경에서 동일한 작동을 구현하는데 문제가 생겼었다. 별거 아닌 문제였지만 이거 하는데 정말 하루는 온전히 갈아넣었던 것 같다. 배포된 백엔드에서 로그를 확인하며 진행해야했기 때문이다. (처음엔 심지어 이 생각도 하지 못했다.) 우리 문제는 redirect_uri였다. 그전에 우리 로그인 로직에 대해 설명하자면 우리 로그인 로직 로컬환경 구성 구글 client id와 redirect_uri, google_scope를 env형태로 관리해주었다. client_id와 google_scope는 변하지 않는 값이므로 따로 github에서 분기처리를 해주지 않았다. 배포환경 구성(Github action) .githu..

멋쟁이사자처럼 11기 프론트엔드트랙장으로서 중앙대학교 멋쟁이사자처럼 11기 아기사자의 리크루팅 과정에 참여했다. 맨날 면접에 면접자로만 참여했지, 면접관으로 참여한 것은 처음이다. 작년 멋사 활동을 하면서 다른 사람들 덕분에 기술적으로든, 그 외적으로든 많은 성장을 이룰 수 있었다. 작년의 목표가 개인적 성장이었다면, 이번년도의 목표는 성장하는 조직을 만드는 것이다. 그러다보니 프론트엔드의 인재상에 아무래도 소프트웨어 장인, 함께자라기의 영향이 많이 들어갔던 것 같다. 리쿠르팅 과정을 거치며 많은 고민을 했고, 많은 것들을 배울 수 있었다. 더불어 나에게도 지원자들과 똑같은 질문을 던져보기로 했다. 고민했던 것들 어떤 점을 중요하게 볼 것인가? 꺾이지 않는 학습의지 가장 중요한 것은 꺾이지 않는 마음, ..