저희 프로젝트 소개페이지에서 가지고 온 자료입니다.📍 ex) “엄마! 나 공부할꺼니까 방해하지마~” 라고 한뒤 10분도 못가서 인스타그램 구경을 하고 계신가요? 이거만 보고 공부해야지 했는데 그새 엄마가 들어오셔서 잔소리를 하신다고요? 우리 서비스와 함께라면 그런일은
유저가 앱에서 기록한 정보를 프론트가 가공해서 백으로 보내주고, 백에서 정보를 받아서 Records 테이블에 저장하는 기능이다. 프론트단에서는 리스트에 그날의 공부시간을 기록한다. 1회 방해를 받을때마다 기록이 초기화된다. 또한 언제 공부한 기록인지를 기록하기위해 IO
인스타그램에 있는것처럼, 팔로우 처리와 언팔로우 처리를 구현했다. 추후, 프론트의 요청에 따라 해당 유저가 팔로우한 유저를 전부 보여주는 기능을 구현할 계획이다. 프론트단에서는 로그인한 유저가 특정 유저 팔로우 버튼을 눌렀을 때 그 유저의 username을 보내준다.
레코드 조회 기능이 조금 더 강화되었다. 우선 검색의 편의성을 위해 Records에 Date 컬럼을 day, month, year로 분리하였다.레코드를 보여주는 기능을 담당하고 있다. 총 2가지가 있는데 하나는 오늘날짜의 records를 바로 보여주는 방식이고, 다른
유저 가입, 정보 수정, 정보 조회를 담당하는 기능이다. 개인적으로 로그인 방식을 4번이나 갈아치우면서 좀 고생을 많이 한 부분이다. 로그인 관련해서는 나중에 따로 적도록 하겠다. 처음에는 Member 테이블 하나로 member 로그인정보와 member 가입정보까지 한
인0런에서 스프링강의를 들으면서 로그인에 관련한 공부를 짧막하게 했었는데, 그때 배운것이 바로 세션을 통한 로그인이다. Front에서 username, password를 서버에서 지정한 url로 보낸다.서버가 이를 받아서 memberRepository에 동일한 이름의
물론 시큐리티 없이도 로그인을 구현 할 수 있지만, 시큐리티를 사용하면 많은 부분을 처리해주기에 편리하니, 공부를 조금 해서 사용하기로 하였다. Spring Security 개요
프론트분들이 Json으로만 보낼수 있다고 하셔가지고 formLogin 받아보려고 이거저거 찾아가면서 개발했는데 결국 안쓰게 된 비운의 코드이다.이 글을 참고하자.json으로 넘어온 username, password를 UserPassowrdAuthentication으로
요즘 사이트중에서 소셜로그인을 지원하지 않는 사이트는 거의 없다. 특히 구글의 경우 구현이 쉬워서인지 범용성이 좋아서인지 없는 사이트를 찾아보는게 더 힘들정도이다. 이런 소셜로그인 서비스를 구현할 때 사용하는 인증규악 프로토콜을 OAuth라 부른다.2006년 Twit
OAuth2의 인증방식에는 크게 4가지가 있다. 각각의 장단점이 있고 많이 서비스별로 많이 사용되는 방식이 구분되어 있는데 이를 확인해보도록 하겠다. 권한 부여 코드 승인 타입리소스 접근을 위한 사용자명, 비밀번호, 권한 서버가 준 AccessCode를 이용해서 리소스
JWT를 이해하기전에 토큰 기반 인증 시스템에 대해 정리하겠다.사실 토큰 기반 시스템을 이해하기 전에 이해해야 하는게 하나 더 있었다.바로 무상태 서버이다. 이 글에 짧게 정리해두긴 했는데 다시 정리해보겠다.Stateless와 반대되는 개념인 Stateful 서버는 클
Json Web Token JWT는 웹 표준 (RFC 7519) 으로, 정보의 안정성 있는 전달을 목표로 한다. 따라서 다양한 개발언어에서 지원되고 있다. JWT는 또한 자가 수용적이다. 자가 수용적 (self-contained) 자가 수용적이란 자신 스스로 모든
길었던 로그인 방식 처리의 마지막이다. 앞선 글에서 설명했던것처럼, 프로젝트에서는 결과적으로 Client Credential 방식을 사용하기로 하였다. 이때, 서버에서는 프론트가 보내주는 정보들을 받아서 회원가입 처리 및 검증처리 등등을 해주면 된다. jwt관련 정보는
https://cake-tarn-9a3.notion.site/ZandiTimer-da8bf49248e74886bb7be01176ab7c9e