#403

리액트로 웹서비스 개발 중 구글sdk 로그인 오류 질문입니다

리액트로 구글 sdk 로그인 구현시 인앱 뷰 (카카오나 인스타그램 네이버앱 등에서 링크로 웹 서비스 접속시) 에서 로그인 실행하면 403 disallowed_useragent 오류가 발생하는데 프론트에서 해결방법 아시는 분 계신가요... 카카오dev에서는 3년째 해결 안하냐고 사람들 화내고 있던데 해결법이 아예 없는 것인지... 크롬에서는 정상으로 작동하는데 일부 앱에서 저런 현상이 발생하네요 며칠 조사해봤는데 16년 이후로 구글에서 보안문제로 웹뷰 접근을 막았다고 하는 거 같던데 혹시 해결하신 분 있으실까요 도와주세요 선생님들

API 호출 시, 응답의 반환하는 방법에 대해 질문이 있습니다.

제가 했던 방식과 다른 새로운 방식을 알게 됐는데 다른 개발자분들은 일할 때 어떤 식으로 통신하는지 궁금증이 생겼습니다. 그리고 이번 기회에 다른 개발자들과 이야기해 보면서 또 어떤 방식이 있는지 알기 위해 커리어리에 첫 글(질문)을 쓰게 됐습니다. —— ***들어가기 전에*** - 신입 백엔드 개발자로 취업 준비 중입니다. - 다양한 방식으로 해보는 걸 좋아하기 때문에 장단점만 있을 뿐 정답은 없다고 생각합니다. - API 요청 시, `Reponse status code`는 클라이언트-서버와의 약속이라고 생각하고 있고, 약속을 했으면 따라야 한다고 생각합니다. - 기간이 짧은 프로젝트이기 때문에 어떤 답변이 오더라도 프로젝트에서 정한 약속을 바꿀 생각은 없습니다. 프로젝트가 끝나고 백엔드 개발자분과 리팩토링을 하면서 의견을 공유해보고 싶긴 합니다. (원하지 않는다면 어쩔 수 없고요..) ***중요*** - 글을 잘 쓰는 편이 아니라 이해가 안되거나 제 말투가 공격적이라고 느껴지는 부분이 있으면 언제든지 말씀해 주세요! - 만약 방식이 잘못됐다고 생각하시면, 그렇게 생각하는 이유와 가능하다면 경험을 공유해주세요! —— # 본문 지금까지 RFC / MDN / IT 기업 기술 블로그 등을 보고 REST API를 공부했고, 설계 원칙에 따라 모든 API 요청에 대한 Response 상태 코드를 200, 400, 401, 403, 404, 500 등과 같이 정확하게 주고받아야 한다고 생각하고 있었습니다. (물론 애매한 경우도 있었습니다) 그런데 최근 짧은 기간 동안 프로젝트를 하게 되었는데, iOS 개발자(2년차 현직)분과 백엔드 개발자(신입 개발자 취업 준비)분께서는 아래와 같은 의견을 주셨습니다. ''' 클라이언트의 입장에서 요청을 보냈을 때, 서버와 연결이 실패한 게 아니라 서버를 통해 정의된 에러 (4xx, 5xx)를 받았으니 통신에 성공한 것이다. 그러므로 API의 모든 요청(권한이 없는 사용자의 요청, 잘못된 리소스 요청, 이미 가입한 사용자가 다시 회원 가입 요청 등)의 `Response status code`는 200을 반환하고 body에 서버에서 응답한 상태 코드(3xx,4xx, 5xx 등)와 함께 커스텀으로 명시한 에러 코드(AUTH-001 등), 에러 메시지를 보내야 한다. ''' 관점을 다르게 보면 그럴 수 있겠구나 싶었고 문득 주변 개발자분들은 어떻게 구현을 하는지 궁금해져서 이야기를 나눠봤는데 그 결과는 반반이었습니다. 아직 그분들도 연차가 높지 않기 때문에 그렇게 설계한 이유와 이점에 대해 자세히 알고 계시지는 못했습니다. —— # 질문 1. 모든 요청의 Response status code로 200을 보내는 건 REST API 설계에 어긋난다고 생각하는데 이렇게 설계하는 이유와 있는지 궁금합니다. 2. 모든 API 요청의 Response status code를 200으로 보내는 방식으로 구현한다면 나중에 어떤 문제가 생길 수 있을까요? (예를 들어 웹으로 확장 등) - 현재 iOS로 개발 중이며, 확장 가능성은 없는 상태입니다. 단순하게 궁금해서 질문드립니다. 3. 만약 두 방식 외에 다른 방식으로 통신한 경험이 있으시면 그 방식을 선택하신 이유와 이점도 궁금합니다.

토큰 기반 인증에서 리프레쉬 토큰 관리

JWT로 토큰 기반 인증을 구현할 때 궁금한게 좀 생겼습니다! 리프레쉬 토큰은 DB에 저장해볼까 했는데 그러면 토큰 기반 인증이 아니라 세션 기반 인증인 것 같아서 고민입니다. DB에 저장하는 순간 Stateless 장점도 없어지는 것 같구… Stateless로 구현한다해도 로그아웃 때문에 블랙리스트 관리해야한다는데, 이러면 결국 Stateful인거 같구… 다른 분들은 어떻게 구현하시는지 궁금합니다! 일단 이렇게 고민해봤습니다. --- <1번 시나리오 - 리프레쉬 토큰을 DB에 저장하지 않는 시나리오>

 1. 액세스 토큰이랑 리프레쉬 토큰은 클라이언트가 저장하고 서버는 저장하지 않는다.
 2. 클라이언트 요청이 왔을 때 리프레쉬 토큰이 만료되지 않았으면 액세스 토큰을 발급해주고, 만료됐으면 액세스 토큰을 발급해주지 않는다. (401 또는 403)
 장점 - DB에 접근할 이유가 없으므로 Stateless 하다. 단점 - 로그아웃을 했을 때 토큰 자체는 무효화시킬 수 있는 방법이 없다.

 <2번 시나리오 - 리프레쉬 토큰을 DB에 저장하는 시나리오> 1. 액세스 토큰이랑 리프레쉬 토큰은 클라이언트와 서버가 각각 저장한다.
 2. 클라이언트 요청이 왔을 때 리프레쉬 토큰이 만료되지 않았으면 액세스 토큰을 발급해주고, 만료됐으면 액세스 토큰을 발급해주지 않는다. (401 또는 403) 장점 - 로그아웃을 했을 때 토큰 자체는 무효화시킬 수 있다. 단점 - DB를 접근해야하므로 Stateful 하다. => 클러스터링이나 샤딩이 도입되면 복잡도가 올라간다.
 --- 1번 시나리오 단점을 극복하려고 블랙 리스트를 Redis에 관리한다는 글들을 종종 봤습니다. 블랙 리스트를 도입 안했을 때 문제는 실제로 겪어본 적이 있어서 공감은 가는데, 이러면 사실상 세션 쓰는거랑 똑같지 않나라는 생각이 듭니다. 인증시 결국 Redis 같은 DB에 접근해서 직접 확인하는 거니까요. 한편으로는 서비스가 매우 많이 커지면 세션이 부담돼서 토큰 기반 인증으로 전환한다는데, 파면 팔수록 점점 세션 기반 인증으로 바뀌는 것 같아서 고민입니다.

프론트엔드 모노레포 배포에 대해 궁금합니다 !

안녕하세요 프론트엔드에서 react로 모노레포구조로 운영하고있는데 현재는 통합 s3 1개에 각 프로젝트 빌드파일을 폴더로 구분하여 올리고 각 프로젝트당 1개의 cloudfront를 통해 해당 프로젝트에 접근하는 1:N 관계로 운영중입니다. 이번에 신규프로젝트가 추가되어 작업을해야하는데 앞으로 추가될 프로젝트가 계속 생길거같아서 그때마다 cloudfront를 추가해줘야하는 번거로움이 걱정됩니다... (앞으로 추가될 프로젝트까지하면 거의 react만 6개...) 이러한 모노레포 구조에서 더 좋은 배포방식이 있거나 cloudfront 한개로 운영할수있는 방법이있을까요?? (cloudfront 한개로 시도해봤는데.. 403,404 부분 index.html 이 한개밖에 설정이 안되어 프로젝트들이 제대로 찾지못해 막혔습니다... ㅠ)

인텔리제이 깃허브 연동 및 푸시

지금 현재 잘 연동 되고 권한도 admin으로 되어있습니다. 파일을 끌어 오는것도 잘 작동하고 커밋도 되고 잘 되는데 푸시만 이상하게 안되네요...ㅠㅠ 오류 코드는 403 뜹니다. 혹시 뭘 설정을 해줘야되나요?

400 or 403

어떤 api 의 요청이 특정 시간대에만 가능하여 서버가 그 외의 시간대를 예외처리한다면, 400 이나 403 중 어떤 status 가 맞다고 보시나요?

사이드프로젝트중 proxy관련 질문있습니다.

현재 사이드프로젝트를 진행중인 취준생입니다. 프론트엔드측에서 로컬에서 원활한 API통신을 위해 proxy를 설정하여 cors를 우회하였는데요. Nextjs13을 사용중이고 rewrites 함수를 next.config 에서 사용하였습니다. 문제는 프로덕션이었습니다. 현재 저희는 Vercel 로 간편하게 배포를 해두었는데요. 프론트 개발서버에서는 cors를 우회하여 api요청과 응답이 정상적이었지만 배포된곳에서는 뜬금없이 403에러가 발생합니다. 혹시 proxy때문에 403에러가 발생하는것일까요?

VM에 VPN(Wireguard)을 통한 접속 방법

안녕하세요. 제발 도움 부탁드리겠습니다. *** 제가 궁극적으로 하고 싶은 것 : 외부에서 노트북으로, 저희 집 데스크톱에 VM으로 띄워 놓은 서버에 VPN을 통해서 접속 (네트워크 지식이 부족하여, 어느 부분이 빠졌는지, 뭘 고려해야하는지, 뭘 알아야하는지... 등 조언과 훈수 부탁드립니다. 구체적인 방법을 알려주시면 가장 좋고요ㅠ) 현재 저의 상태입니다. 1. LG 유플러스 인터넷 사용, 집에 있는 데스크톱에 랜선을 꽂아서 인터넷 사용중 (IP : 192.168.219.102) 2. VMware - Bridged 방식으로 VM 서버(Ubuntu 22.04) 하나를 띄워 놓음 (IP : 192.168.219.201) 3. 위의 VM 서버에 Wireguard VPN을 설치 (VPN 서버 + 개인용 웹서버로 사용하기 위해) 4. https://jjeongil.tistory.com/2062 블로그를 보며 VPN 서버 구축을 함 5. Wireguard 설정 ㅇ 서버측 wireguard 설정(VM) [Interface] Address = 192.168.219.1/24 SaveConfig = true PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -t nat -A POSTROUTING -o ens33 -j MASQUERADE PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -t nat -D POSTROUTING -o ens33 -j MASQUERADE ListenPort = 51820 PrivateKey = xxxxxxxxxx= [Peer] PublicKey = xxxxxxxxxx= AllowedIPs = 192.168.219.202/32 ------------------------------------------------------------- ㅇ 클라이언트쪽 wireguard 설정(노트북) [Interface] PrivateKey = xxxxxxxxxx= Address = 192.168.219.202/24 [Peer] PublicKey = xxxxxxxxxx= AllowedIPs = 0.0.0.0/0 Endpoint = 192.168.219.201:51820 ============================================================= [ 로그 ] 2023-09-22 16:18:28.666678: [TUN] [srm-pjt-vm-server] Starting WireGuard/0.5.3 (Windows 10.0.22621; amd64) 2023-09-22 16:18:28.667384: [TUN] [srm-pjt-vm-server] Watching network interfaces 2023-09-22 16:18:28.669947: [TUN] [srm-pjt-vm-server] Resolving DNS names 2023-09-22 16:18:28.669947: [TUN] [srm-pjt-vm-server] Creating network adapter 2023-09-22 16:18:28.750000: [TUN] [srm-pjt-vm-server] Using existing driver 0.10 2023-09-22 16:18:28.762403: [TUN] [srm-pjt-vm-server] Creating adapter 2023-09-22 16:18:28.967072: [TUN] [srm-pjt-vm-server] Using WireGuardNT/0.10 2023-09-22 16:18:28.967588: [TUN] [srm-pjt-vm-server] Enabling firewall rules 2023-09-22 16:18:28.938662: [TUN] [srm-pjt-vm-server] Interface created 2023-09-22 16:18:28.972410: [TUN] [srm-pjt-vm-server] Dropping privileges 2023-09-22 16:18:28.972410: [TUN] [srm-pjt-vm-server] Setting interface configuration 2023-09-22 16:18:28.972932: [TUN] [srm-pjt-vm-server] Peer 1 created 2023-09-22 16:18:28.974501: [TUN] [srm-pjt-vm-server] Monitoring MTU of default v4 routes 2023-09-22 16:18:28.974501: [TUN] [srm-pjt-vm-server] Interface up 2023-09-22 16:18:28.977259: [TUN] [srm-pjt-vm-server] Setting device v4 addresses 2023-09-22 16:18:28.995686: [TUN] [srm-pjt-vm-server] Monitoring MTU of default v6 routes 2023-09-22 16:18:29.023405: [TUN] [srm-pjt-vm-server] Setting device v6 addresses 2023-09-22 16:18:29.072431: [TUN] [srm-pjt-vm-server] Startup complete 2023-09-22 16:18:29.070847: [TUN] [srm-pjt-vm-server] Sending handshake initiation to peer 1 (192.168.219.201:51820) 2023-09-22 16:18:34.106156: [TUN] [srm-pjt-vm-server] Handshake for peer 1 (192.168.219.201:51820) did not complete after 5 seconds, retrying (try 2) 2023-09-22 16:18:34.106156: [TUN] [srm-pjt-vm-server] Sending handshake initiation to peer 1 (192.168.219.201:51820) 2023-09-22 16:18:39.107654: [TUN] [srm-pjt-vm-server] Sending handshake initiation to peer 1 (192.168.219.201:51820) 2023-09-22 16:18:44.115294: [TUN] [srm-pjt-vm-server] Sending handshake initiation to peer 1 (192.168.219.201:51820) 2023-09-22 16:18:49.267198: [TUN] [srm-pjt-vm-server] Handshake for peer 1 (192.168.219.201:51820) did not complete after 5 seconds, retrying (try 2) 2023-09-22 16:18:49.267198: [TUN] [srm-pjt-vm-server] Sending handshake initiation to peer 1 (192.168.219.201:51820) 2023-09-22 16:18:54.340284: [TUN] [srm-pjt-vm-server] Handshake for peer 1 (192.168.219.201:51820) did not complete after 5 seconds, retrying (try 2) 2023-09-22 16:18:54.340284: [TUN] [srm-pjt-vm-server] Sending handshake initiation to peer 1 (192.168.219.201:51820) 2023-09-22 16:18:59.355253: [TUN] [srm-pjt-vm-server] Sending handshake initiation to peer 1 (192.168.219.201:51820) 2023-09-22 16:19:04.414034: [TUN] [srm-pjt-vm-server] Handshake for peer 1 (192.168.219.201:51820) did not complete after 5 seconds, retrying (try 2) 2023-09-22 16:19:04.414034: [TUN] [srm-pjt-vm-server] Sending handshake initiation to peer 1 (192.168.219.201:51820) 2023-09-22 16:19:07.916126: [TUN] [srm-pjt-vm-server] Shutting down 2023-09-22 16:19:07.922350: [MGR] [srm-pjt-vm-server] Tunnel service tracker finished

next.js / s3 + cloudfront 새로고침 403 문제... ㅜㅜㅜㅜㅜ

안녕하세요 ! next.js 로 프로젝트를 진행중에 s3 + cloudfront로 배포를 진행하였습니다 ! route53으로 도메인 지정까지 완료되어 무사히 배포된줄알았는데… 첫 index.html 페이지를 제외한 부분에서는 새로고침시 403에러 access denined가 떠서 구글링 해보니까 403 에러시 200코드와 함께 index.html로 보내주는 해결방법이 가장 많더라구요…! 근데 지금 개발중인 서비스가 이메일과 sms로 알림발송시 페이지 링크가 발송되어 저 방법으로 해결시 링크 클릭시 리다이렉트되어 index.html로만 접속되는거같은데…. 따른 해결방법이 더 있을까요? 고수님들의 답변이 시급합니다 … ㅜㅜ

스프링 시큐리티 접근제어 문제 질문

스프링 시큐리티에 ​ AbstractAuthenticationToken authentication = new UsernamePasswordAuthenticationToken( "email", null, AuthorityUtils.createAuthorityList("admin") ); 이런식으로 값을 넣어주고 ​ 컨트롤러에서 SecurityContextHolder.getContext().getAuthentication() 로 값을 뽑았을 때 [Principal="email", Credentials[PROTECTED], Authenticated=true, Granted Authorities=[admin]] ​ 이렇게 값이 잘 옵니다. ​ 문제는 시큐리티 콘피그에서 ​ http.authorizeRequests() .mvcMatchers("/offers/**").hasAuthority("admin") 으로 설정해놓았는데 offers에 접근하면 403 forbidden에러가 뜹니다.... ​ hasRole로 바꾸어도 마찬가지고요. ​ 왜 해당 에러가 발생하는지 궁금합니다. csrf().disable()도 하였습니다. ​ SecurityContextHolder.getContext().getAuthentication()에 있는 값으로 SecurityConfig에 있는 권한을 설정하는 것이 아닌가요? ​ 검색하며 시도를 해보았지만 해결되지 않아 질문합니다.