[WIL] 항해 99 실전 2주차

김하나·2022년 11월 20일
0

WIL

목록 보기
9/17

로그인 기능

뷰 구현하기

아마 실전을 하는 내내 로그인만 하게 될 가능성이 높다. 다른 팀원들이 여러 기능을 쉽게 쉽게 해내는 것에 비해 비중도 작고 중요한 기능은 아니지만, 내입장에서는 아무것도 아닌게 아닌거 같다.

뷰를 짜는 것은 쉬웠다. 지난주에 했던 모달이 큰 도움이 되어서 삼항 연산자를 이용해 페이지를 열고 닫고 넘기고 하는 것들은 자연스러워졌다.
페이지는 넘버를 지정해주고 더하기 해서 클릭할때 그 페이지를 보이게 하면 됐다. 버튼 한개당 페이지 한개라고 생각해서 쉬울줄 알았는데 생각보다 경우의 수가 꼬이고 있다.
+1 -1을 해줘서 페이지 자체를 넘기는 것은 문제가 아니다.
서버에 연결한 뒤 데이터를 보내고 나서 어떤 경로로 원래 페이지를 보내줄지 결정해야하고,
그것보다도 로그인이 된 유저는 이 페이지 자체에 접근이 불가능 해야한다.
이 처리를 해주지 않으면 그만 번호가 꼬여서 아무것도 보여주지 않는 페이지가 떠버린다...

로그인 로그아웃 기능을 간과하면서 다들 쉽다쉽다 하는데..
너무 쉬워서 그런지 블로그에 올라와 있는 글도 많이 없다. 양질의 자료를 찾기가 쉽지 않은 부분이어서 되려 어려움을 느끼게 되었다.

그냥 아이디 패스워드 정보를 서버로 넘기고 토큰을 받아와서 세션스토리지에 저장하는 단순한 기능만 떠올린다면 진작 끝났어야 하는데,

로그인 페이지도 디자이너의 요청에 따라 다양한 방식으로 구성될 수 있어서 페이지를 작성하는 도중에 아이디는 맞게 쳤는지, 비밀번호는 올바르게 들어갔는지 검사를 해야한다. 거기에 뒷페이지에 새로운 정보 입력란이라도 있으면, 앞쪽에서 이메일 중복검사는 해주고 넘어가야 한다.

이 과정들은 지난 프로젝트들에서 접하지 못했던 부분이라 내 입장에서는 새로운 기능들이었다.
물론 다른 페이지에 비하면 단순하고 쉬워보인다는 것이 함정이지만, 지금껏 달리기반 사람들과 차이를 느끼면서 공부해왔는데 실전에 와서 비등하게 할리가...ㅋㅋ
그저 내가 맡은 부분을 오차 없이 잘 해내는 것만 생각하고 있다. 조금 여유가 된다면 CSS를 다듬는 일에 합류할 수 있으면 좋겠다.

보안 문제에 대한 고민

로그인에서 또 한가지 봉착한 어려움은 자동로그인 구현이다. 토큰을 세션스토리지에 저장하지 않고, 로컬 스토리지에 저장하는 방식으로 이해하면 쉽게 느껴지지만 그렇게 단순한 문제가 아니었다.

지난 프로젝트들은 배포를 목표로 둔 프로젝트들이 아니어서 유저의 편의성이나 안전성보다는 기능구현을 연습하는 것만으로 의미가 있었다고 하면,
이번 프로젝트의 성격은 완전 다르다.

실제로 유저에게 홍보해서 그들의 정보를 받고, 사이트를 운영할 계획이 있기 때문에 로그인을 대충해서는 절대 안된다.

특히 로컬스토리지에 저장된 토큰의 경우 해킹의 우려가 있기 때문에 보안처리를 해야한다는데 거기서부터 험난한 산이 눈앞에 보였다.

이미 앞에 유효성 검사를 할때도 @가 들어있는지, . 이 들어있는지, 파악해서 에러 메세지를 띄워줬고, 잘못된 내용이라면 로그인 버튼이 활성화 되지 않게 설정했다.

일반회원의 경우 회원가입과 동시에 로그인 처리를 해야해서 토큰을 회원가입하는 코드에서도 저장할수 있게 했는데,

이걸 보안처리까지 해서 차후에 자동으로 로그인이 되게 하려니 방법이 떠오르지 않았다.

나도 요즘 구글에서 아이디와 비밀번호 관리를 해주는걸 워낙 편하게 사용하고 있던터라 이게 어떻게 작동할까 궁금했는데...
만드려고 하니 정말 어렵다.
멜론으로 음악 들으려고 앱에 들어가도 매번 로그인을 요구하지 않고 자동으로 로그인 처리가 되어 편리한데, 이걸 내가 구현할수 있을까 하는 약간의 두려움이 엄습해왔다.

어플이나 앱은 단말기에 설치해서 설치된 그 단말기의 asyncStorage에 저장을 하면 된단다.
생각해보니 휴대폰을 해킹하기 위해서는 사용자가 어떤 정보를 넘겨주지 않는 이상 가만히 있는 폰을 해킹하긴 어렵다. 악성코드가 심겨있는 앱을 깔면 그때부터 난리나는 것이지만..

웹은 조금 다른거 같다. 보안을 신경써야 할텐데...
이 난관을 이번주안에는 반드시 해결해야 한다며...
다음주에는 난관을 해결했다고 기쁘게 WIL을 쓸수 있었으면 좋겠다.

자동로그인은 디자이너의 요청이었으므로 반드시 수행하고 싶은 목표다.
그것만 되면 디자이너의 요청대로 기능 구현은 끝나는데,
잔기능들이 아직 완성되지 않았다.

각종 메시지 구현

유저가 아이디와 비밀번호 쓸때 생각보다 많은 메시지를 띄워야 한다.
아까도 말했듯 형식에 알맞게 썼는지 유효성을 검사해야하고, 서버에 내용을 미리 보내서 중복되는게 없는지 체크해야 하고, 실패하면 어떤 사유로 실패를 하게 되었는지 메시지를 띄워줘야 하는데, 빈칸으로 제출하려 시도 할때도 메시지를 띄워주어야 하나; 빈칸은 애초에 제출할 수 없도록 버튼을 비활성화 하는 방식으로 만들었기 때문에 메시지를 볼일은 없을 것 같다.
다만, 유저가 다시 쓰려고 input창의 내용을 다 지워도 밑에 메시지가 사라지지 않는 것을 보니.. 다 지웠을때 state도 한번 비워줘야 할것 같다. 이 부분은 수정을 해야겠다.

로그인 하고 잠시 지연되는 건 없어서 중간에 뭘 넣진 않았지만, 꾸미려면 얼마든지 꾸밀수가 있는게 로그인 회원가입 페이지 인거 같다.

폼데이터 형식

사진 정보를 받아서 넘기는 부분은 폼데이터를 활용했는데,
예전 프로젝트에서는 항목별로 state를 만들어서 formdata.append.(데이터이름, 데이터state명) 해서 묶어서 보내줬는데,

이번에는 형식이 좀 달랐다. 다르다기 보다는 추가되었다.

백엔드 분들이 이렇게 보내기를 요청해왔기 때문에 이번에는 형식을 좀 바꾸어보았다.
기본적으로 form데이터로 보내는 것은 맞지만,
사진을 제외한 나머지 정보를 blob으로 만들어서 묶어주었다. json형식으로.
이 과정에서 사진 파일 input Dom에 직접 접근을 해야 하는거 같은데... 흠...
내용이 많지 않고 멀티미디어가 없는데도 blob을 써야하는 것인지 의문이 들었지만, 일단 이렇게 써야 서버가 받아들일수 있어서 데이터는 이렇게 넘기는 것으로...
이미지만 dom에 직접 접근하지 말고 state를 만들어서 다시 집어 넣어봐야겠다.
컴포넌트가 재사용될 때는 당연히 Dom에 직접 접근 하는 방식은 안되겠지만 지금은 단일한 페이지에 조촐한 데이터를 넘기고 있어서 크게 문제가 될 것 같진 않다.

리팩토링을 하는 과정에서 지금 구현된 기능들이 보다더 매끄럽게 진행될 수 있도록 만들고 싶은데 ...
경시 되고 있는 로그인 기능이라...
공부를 조금 해보아야 될거 같다. 홀로..

profile
코딩하고 글씁니다

0개의 댓글