티스토리 뷰

 

1️⃣ 회원정보수정 오류 (userID -> session)

오류1)

수정 화면에서 작성을 하고 저장을 누르면

 

 

500 에러 발생

 

원인)

root-context에 mapper 등록을 안한 실수

 

해결)

root-context에 MyPageMapper 등록

 

아주 바보 같은 실수였다.

이 실수를 기점으로 매퍼를 생성하고 root-context에 등록안하는 일은 앞으로 절대 없을 것 같다. 😂

 


 

 

2️⃣ 코드 수정

💡 userID에서 추출하여 사용하는 방법 vs session

회원 정보 수정 시 로그인 정보를 userID에서 가져오는 방법과 세션(session)에서 가져오는 방법 간에는 몇 가지 차이가 있습니다. 어느 것이 더 유용하다고 판단되는지는 사용자 경험과 보안 측면에서 고려해야 할 사항에 따라 다릅니다.

userID에서 가져오는 방법:
실시간 정보 갱신: 로그인 정보가 변경되면 즉시 반영이 가능합니다. 즉, 다른 사용자가 수정한 정보를 바로 반영할 수 있습니다.
데이터 일관성: 세션에 저장된 정보가 로그인 시점의 정보일 수 있기 때문에, 로그인 이후 사용자 정보가 변경되었을 경우에는 일관성이 떨어질 수 있습니다.


세션에서 가져오는 방법:
캐싱과 효율성: 세션에서 가져온 정보는 한 번 로그인하면 서버의 성능을 고려해 일정 시간 동안 캐싱됩니다. 따라서 매 요청마다 DB에서 정보를 가져오는 것보다 효율적일 수 있습니다.
보안: 로그인 정보는 세션에 저장될 때 암호화되어 안전하게 보관됩니다. 세션은 클라이언트에 저장되는 것이 아니라 서버 측에서 관리되므로, 클라이언트에서 조작이 어려워 보안성이 좋습니다.


어느 것이 더 유용할까:
실시간 갱신이 중요한 경우: 정보의 실시간 갱신이 중요한 경우에는 userID에서 직접 정보를 가져오는 것이 적합합니다. 예를 들어, 다른 사용자에게 자주 노출되는 정보라면 실시간 갱신이 필요할 수 있습니다.
보안과 효율성이 중요한 경우: 보안과 효율성이 중요한 경우에는 세션에서 정보를 가져오는 것이 적합합니다. 로그인 정보를 세션에 저장하여 클라이언트와의 통신을 최소화하고, 보안적인 측면에서 세션을 신뢰할 수 있게 구성합니다.

개발 상황 및 요구사항에 따라 두 방법을 조합해서 사용하기도 합니다. 종종, 로그인 시에는 세션에 정보를 저장하고, 필요한 경우에만 userID에서 실제 정보를 가져오는 방식이 적용되기도 합니다.

 

로그인 정보를 userID에서 추출하여 사용하는 방법으로 로직을 구현했었는데 세션에서 로그인 정보를 가져오는게 보안와 효율성에 더 좋을것같아 수정했다.

// 회원 정보 확인
@GetMapping("/memberInfo")
public String memberInfo(HttpSession session) {
    MemberDTO dto = (MemberDTO) session.getAttribute("loginInfo");
    return "mypage/memberInfo";
}

 

 


 

 

2️⃣ 회원 정보 수정 화면 구현

// 회원 정보 수정 화면 
@GetMapping("/MemberUpdateForm")
public String memberUpdateForm() {
	return "mypage/memberUpdateForm";
}

 

 


 

 

3️⃣ 회원 정보 수정

@PostMapping("/memberUpdate")
public String memberUpdate(HttpSession session, MemberDTO updatedDTO) {
	 MemberDTO currentDTO = (MemberDTO) session.getAttribute("loginInfo"); //현재 로그인 정보 가져오기
	 updatedDTO.setUserID(currentDTO.getUserID());    //currentDTO에서 가져온 정보를 updatedDTO에 업데이트
	 service.memberUpdate(updatedDTO); //updatedDTO를 사용하여 회원 정보 업데이트
	 session.setAttribute("loginInfo", updatedDTO);   //수정된 정보를 세션에 다시 저장
	 return "redirect:memberInfo"; // 수정 후 회원 정보 페이지로 이동해 업데이트 된 회원 정보 확인
}

 

RESTful API 디자인 원칙에 의해 회원 정보 수정은 리소스의 상태를 변경하는 작업이기 때문에 HTTP POST 요청이 적합하다. 

먼저 현재 사용자의 세션 정보를 가져오기 위해 매개 변수로 세션 객체와 수정할 회원 정보를 담는 MemberDTO 객체를 사용했고, 바로 다음 코드에서 세션에서 현재 로그인 된 사용자의 정보를 가져오게 된다.

그리고 현재 로그인 된 사용자의 ID를 수정할 DTO에 설정하고, 서비스 계층에서 회원 정보를 업데이트, 그렇게 수정된 회원 정보를 세션에 다시 저장한다.

회원 정보가 성공적으로 업데이트된 후, 회원 정보 페이지로 리다이렉트 해준다.

 

 


 

 

4️⃣ 멘토링

  • 지도에 좌표 같은 것을 프론트로 구현하면 백엔드도 뒷받침 되어주어야 함 ⇒ 백엔드 로직에 관한 많은 고민 필요함
  • 데이터 자료만으로 구현을 못하는 것들 (깃발, 좌표) 어떻게 표현할지 고민과 학습 필요
  • 나의 위치 기반으로 표시하는 기능들 ⇒ 거리 계산을 어떻게 할지 수학적인 고안 필요
  • 투어 4.0 API 초기에 데이터 넣는 방법을 고안
  • DB의 스키마 entity 자체를 바꿀 일이 생길 경우 ⇒ 원격에 있는 것은 merge가 된 후에 변경하는 것을 추천
  • 외부 API는 하루 중단되는 경우가 있다 ⇒ 그런 경우 어떻게 할지 고민 필요 ( 현재 수준의 고민은 아님 )
  • 테이블 설계, 로직 설계 등에 집중하기
  • 난이도가 높고, 부가적인 기능은 빼고 완성도에 집중하기
  • 예를 들어, 일정 만들기에 깃발을 만들고 좌표를 찍는 것들은 과감히 빼도 괜찮을 것 같다.

전체적으로 프론트단 구현보다는 백엔드적인 기능들을 집요하게 파고들 것에 집중하는 것을 권하셨다.

그리고 많은 기능 구현보다는 적은 기능이라도 완성도에 집중하기로!

 

 

 

프로젝트 보완할 점

  • 회원가입 이메일 인증 구현
  • 비밀번호 암호화 (단방향 알고리즘 암호화)
  • 메인화면에 지역 검색 보다는 좋아요 많은 게시글 나타나게 하기
공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
링크
TAG
more
«   2024/05   »
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31
글 보관함