함께 알아가는 IT 정보

결론부터 말하자면 고쳤다.문제의 원인그래서 원인이 뭐였냐?백엔드가 https를 못알아먹는다. -> 이에 대한 설정을 추가함.그래도 안된다. -> 강제로 설정할 수 있게끔함.간단하게 말하면 이렇게 고쳤음.제일 처음엔 구글콘솔에 등록 하지 않은 줄 알았다. 그래서 가보니까 되어있네?그럼 뭐가 문제일까 싶어서 로그인 창을 보니까 개발자가 볼 수 있게 문제가 뭔지 보여주는 곳에서400 에러를 명시해주고 로그인 버튼을 눌렀을 때 나온 url을 보여주는데 여기서 http:///google/login/url뭐 이런식으로 되어있었음. 그러니까 난 nginx 초기 설정을 할 때 https 에 대한 설정을 끝냈는데 이상하게 로그인 버튼을 클릭하면 그게 해체가 된거.그래서 원인은 url이 이상하다. 였다.그래서 우째 고침?..

사실 컨테이너로 해보고 싶어서 어제 하루종일 붙들고 있다가 포기하고 서버 컴퓨터 다시 생성해서 다시 처음부터 했다.괜히 일 벌려서 일 다시 하게 생겼네.우선 컨테이너로 왜 하려고 했냐면 나는 모든게 다 한 네트워크 안에서 돌아가게 하는게 지금의 배포 구성보다 더 효율적이지 않을까? 라고 생각했고 관리도 용이할 거라는 생각때문에 기존에 있던 자동배포 로직 자체를 싸그리 다 고쳐봤는데 이게 자동으로 업로드까지는 되는데 nginx에 코드로 도메인이랑 설정들 넣는데에서 계속 문제가 발생했다.(여기 릴리즈 보면 총 54번 시도해본거다. 지금도 서버 키면서 중간중간 비는 시간에 이거 작성중)지금 이걸 막 작성하고 있는 시간이 일요일 오후 7시 쯤인데 어제 한 오후 3시? 부터 시작해서 아침 8시까지 붙잡고 있다가 ..

가비아에서 도메인 구입, 이번엔 안까먹고 타사 네임서버 작성함. (dnszi.com 네임서버 작성)오케이 구매 완료함.그니까 도메인 관리는 dnszi에서 할거임.여튼 구매 했으니까 다음으로는 배포 테스트에 대한 전략이 필요함.내가 배운대로 보자면 main이나 master브랜치 밖에 없었어서 push 할 시에 자동 배포 빌드가 이루어진건데 지금은 굳이 따지자면 협업중이고 그런식으로 접근하면 위험하다는 생각이 듦.그래서 이걸 develop 브랜치에서 파생하는 브랜치를 하나 더 생성하고 여기서 배포에 대한 테스트를 진행하면 좋겠다가 결론임.그래서 staging이라는 브랜치를 생성해서 develop을 pull 해왔음.이제 여기서 내 맘대로 좀 주물러보면 됨. 우선은 도커파일이 준비가 되어야하니까..우선은 도커파..

리프레시 토큰은 Redis에서 중앙화 해서 관리하고, 엑세스 토큰은 지금 브라우저 스토리지로 관리중임.허나, 스토리지는 XSS공격에 굉장히 취약함. 사실 소셜 로그인이고 빼갈 정보가 이메일정도 밖에 없어서 대충이렇게 하려고 했는데 그래도 이왕하는거 완벽하게 하고 싶다는 생각이 들어서 쿠키를 도입하기로 함.그래서 백엔드에서 헤더에 json을 태워보내던 방식을 쿠키로 고쳤음.백엔드 수정사항 ->CustomOAuth2SuccessHandler 클래스에서 onAuthenticationSuccess에 기존 헤더에 JWT 태워서 리턴하던 로직을 쿠키로 보내주는 것으로 변경 (setHttpOnly 설정으로 XSS 공격에 대한 방어 설정함)AuthController클래스 생성해서 인증로직과 member 로직 완전 분리..

프론트useUserLoction 함수 수정날씨 데이터 새로고침 문제 해결유저 위치 저장, 수정 로직 이슈 해결백엔드위치 삭제시 만약 즐겨찾기라면 초기화 로직 구현자잘한 문제가 발견될 때 마다 재깍재깍 수정중.아 그리고 첫 로그인 사용자에 대한 처리가 있으면 좋겠다는 생각이 들어서 어떻게 구현할지 고민을 좀 해봤는데 첫 로그인이라면 JWT에 뭐 new customer 같은 값을 태워 보내주면 되지 않을까라는 생각을 함.하는김에 이상하게 userId 태워보내던거 제대로 JWT 토큰에 추가함.첫 로그인 사용자에 대한 처리 함.이렇게 하고 기존 사용자에 대한 알람도 처리함.어떻게 했냐면 JWT에 isNewUser라는 참 거짓 하나 추가해서 첫 로그인인지 아닌지 판별하게끔 했음.여기 보면 이게 트루라서 작동한거...

일단 develop으로 머지 시키고 개꿀잠을 자버림. (학원 못감, 사실 너무 늦게 잔 것도 있고 무조건 해결하고 자야겠다 싶어서 감기기운도 좀 있고 머리도 아픈데 끝까지 붙들고 JWT 모든 문제 해결 이후, 기존 로직들이 유지되게끔 수정하고 잠.)근데 이제 팀원들이 머지하고 난 이후 서버가 돌아가지 않는다고 연락이 옴.디스코드로 한 4시간 붙들고 얘기를 했는데, 나는 아무문제 없이 잘 작동하는데 팀원들만 안되는 기이한 상황이였음.여기 보면 당시 어지러운 상황이 좀 남아있긴한데,,결론은 윈도우랑 맥의 차이기도 했고,,여튼 JWT인증을 위해서 나는 뭐 영어로 우리팀 개짱짱맨이고 아무도 막을 수 없으셈 이런걸 영어로 작성해서 Base64인코딩한 값을 넣었었음. 이 과정에서 맨 마지막에 =이라는 문구가 하나 ..

지금 로그인 상태를 확인하는 방법이 꽤나 괴랄하다.세션 유지 방식sessionManagement.sessionCreationPolicy(SessionCreationPolicy.IF_REQUIRED)이 설정은 인증된 사용자가 있을 경우 세션을 생성해서 인증 상태를 유지하겠다는 의미. 즉, 로그인한 사용자는 세션을 통해 계속 인증 상태를 유지할 수 있음.인증 상태 확인Spring Security는 SecurityContextHolder와 Authentication 객체를 사용해 인증 상태를 자동으로 확인.예를 들어, /api/** 경로에 접근하려면 사용자가 인증되어야 하도록 설정되어 있고, 인증되지 않은 경우에는 자동으로 customAuthenticationEntryPoint가 호출되서 401 Unautho..

일단 유성우든 대접근이든 한번에 요청해야하는 데이터량이 적지는 않을 것이라 판단한다.그럼 API 호출을 여러번 하게 되고, 그건 성능과 비용문제로 직결됨.그래서 이번에 도입해놓을 것은 Betch임.Batch가 유용한 상황대량의 이벤트 추가/수정/삭제:유성우나 행성 대접근 데이터처럼 수십 개, 수백 개의 이벤트를 한꺼번에 처리해야 할 때.개별 요청을 보내면 네트워크 부하와 속도 문제가 생길 수 있는데, Batch로 묶으면 한 번에 처리 가능.API 호출 비용 절감:구글 캘린더 API는 호출 횟수 제한(쿼터)이 있음.Batch를 사용하면 여러 요청을 하나의 HTTP 요청으로 합쳐 보내므로 쿼터 소모량 감소.일관된 데이터 처리:여러 이벤트를 처리하는 중 일부 실패할 수 있음.Batch를 사용하면 요청 단위로 ..

우선은 리포지토리와 엔티티를 생성하고 그에 맞게끔 연결은 했는데.DB를 추가 한 이유가 사용자 UI 개선의 목적도 있지만 결국 결론은이제 DB저장을 하면 고유한 ID 번호가 생김 -> 복잡한 형태의 고유 ID를 입력하기 싫음.이거임.그래서 지금 작성한 로직을 DB ID 번호로 돌아가게끔 해야됨. 지금은 googleEventId를 내가 입력을 해줘야지 찾는데, 그게 아니고 고유 번호를 따라서 googleEventId를 찾아서 캘린더까지 접근해서 수정 삭제 읽기가 가능하게끔. 현재 코드는@Service@RequiredArgsConstructorpublic class PublicCalendarEventService { private final CalendarEventManager calendarEvent..

우선 API 연결을 위해서 다시 구글 콘솔로 진입.추가해줬음.우선 약간의 문제가 있다면 나는 데이터를 보여줄 캘린더 하나, 그리고 사용자가 천체 관측 일정을 관리할 수 있는 캘린더 하나를 이 구글 캘린더로 제공을 하고 싶었는데, 이게 내 공용 캘린더를 읽기전용으로 전환해서밖에 보여줄 수 없다는 결론에 도달함.그게 아니라면 데이터를 보여줄 캘린더 따로 구축, 또 사용자는 구글 캘린더를 사용해야되는데, 이 과정에서 공용 데이터 캘린더 -> 사용자 캘린더로의 일정 복사도 복잡해질 것 같고.. 그래서 일관성 있게 그냥 내 구글 계정에 캘린더를 희생하기로 함.여튼 결론이 뭐냐?공용 캘린더에 이벤트 추가 및 공유: 천문 이벤트와 관련된 정보를 하나의 공용 캘린더에 추가하고, 이 캘린더를 사용자들에게 읽기 전용으로 ..