Chore/#134 API 보안 설정 로직 개선 및 개발/배포 환경 분리 - #147
Conversation
|
Caution The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased. |
| tasks.register('copyConfig', Copy) { | ||
| from("${rootProject.projectDir}/backend_config/dev/monolithic") { | ||
| include 'application.yml' | ||
| include 'application-prod.yml' |
There was a problem hiding this comment.
spring boot 에서는 application.yml -> application-prod.yml 순으로 적용됩니다. 그러나 application-prod.yml 에는 ddl-auto 설정이 명시되어있지 않아 application.yml 의 ddl-auto: create-drop 이 적용될 것으로 예상됩니다. 따라서 prod에는 validate 또는 none을 명시해야 합니다.
There was a problem hiding this comment.
확인 감사합니다. 말씀하신대로 DB 관련 설정은 prod/dev 환경에서 분리해서 관리하는 것이 좋아보입니다
| from("${rootProject.projectDir}/backend_config/dev/monolithic") { | ||
| include 'application.yml' | ||
| include 'application-prod.yml' | ||
| include 'application-dev.yml' |
There was a problem hiding this comment.
추가로 운영 환경에서 dev profile의 비활성화가 보장되는 지 궁금합니다. application.yml에는 active: dev, auth 가 활성화 되어 있어서 별도 처리가 없다면
DevAuthController의 POST /dev/users/auth가 permitAll 상태로 활성화되어 인증없이 ADMIN 토큰을 발급받을 수 있어 보입니다.
There was a problem hiding this comment.
확인 감사합니다.
해당 부분이 수동 테스트 과정에서 확인되지 않은 이유는 IntelliJ Run Configuration에서 설정한 profile이 application.yml의 spring.profiles.active보다 우선 적용되기 때문입니다.
profile은 application.yml에 고정하기보다 JAR 실행 시 외부에서 전달하는 방식을 고려하고 PR을 구성했습니다. 동일한 Docker 이미지를 사용하면서 실행 환경에 따라 dev/prod 등 필요한 profile을 지정하여 환경별 설정을 분리하기 위함입니다.
따라서 현재 application.yml에 설정된 profile 관련 부분은 제거하도록 하겠습니다.
|
Swagger는 application-prod.yml에서 비활성화하고 application-dev.yml에서 활성화하여 환경별로 분리한 것으로 이해했습니다. 다만 Swagger 관련 permit-all 경로는 공통 application.yml에 남아 있습니다. Swagger 자체가 비활성화되면 실제 엔드포인트는 노출되지 않겠지만, 환경 분리 관점에서 이 규칙 역시 dev 설정으로 분리하지 않은 이유가 궁금합니다. |
|
1. 사용할 수 있는 대안 다만 이 방식은 공통으로 사용되는 Security 설정이 중복되는 문제가 있고, 현재 개발/운영 환경에서는 Swagger 관련 경로를 제외하면 API 접근 정책을 동일하게 사용하고 있습니다. 혹은 개발/운영 환경에서 독립적으로 관리되어야 하는 API 접근 정책만 별도로 구성하고, 나머지는 공통 2. 현재 방식을 채택한 이유 이전에 말씀드린 것처럼 Swagger UI와 관련 endpoint는 따라서 이에 따라 불필요한 복잡도를 추가하지 않고, 현재와 같이 공통 이러한 판단에 대한 리뷰어님의 의견 부탁드립니다. |
PR 타입
작업 내용
주의사항
관련 이슈: #134
테스트 결과
1. 통합 테스트 결과
2. 수동 테스트 ( profile = dev일 때 swagger 접속 )
3. 수동 테스트 ( profile = prod일 때 swagger 접속 )
4. 수동 테스트 ( permit-all로 설정한 요청 경로 접근 테스트 ( 토큰 없을 때 ) )
PR 체크리스트