Refactor: application.yml 설정 수정, Spring Security 설정 - #14
Conversation
|
ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughAdds a Spring Security config that permits all requests (stateless) and disables CSRF/form-login/HTTP Basic. Updates runtime and build configuration: Kafka, Redis, Tomcat, tracing/Zipkin, JSON logging, Docker build image, and .gitignore. ChangesQueue service runtime & security
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Tip 💬 Introducing Slack Agent: The best way for teams to turn conversations into code.Slack Agent is built on CodeRabbit's deep understanding of your code, so your team can collaborate across the entire SDLC without losing context.
Built for teams:
One agent for your entire SDLC. Right inside Slack. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In
`@src/main/java/org/ticketing/queue/infrastructure/config/QueueSecurityConfig.java`:
- Around line 11-29: The QueueSecurityConfig class currently exposes a
permissive SecurityFilterChain (securityMatcher("/**"),
anyRequest().permitAll()) in all environments; restrict it to tests by adding
the Spring profile annotation to the class (e.g., annotate QueueSecurityConfig
with `@Profile`("test")) or remove the entire class if it's no longer needed;
update imports to include org.springframework.context.annotation.Profile and
ensure the bean remains only active under the intended profile so production
authentication is not bypassed.
In `@src/main/resources/application.yml`:
- Line 6: Replace the hardcoded Config Server URI in the import declaration so
deployments can override it at runtime: update the line that currently reads
"import: optional:configserver:http://localhost:10002" to reference an
environment/property placeholder (e.g. use ${CONFIGSERVER_URI} or a Spring
property) and keep the same "import: optional:configserver:" prefix so the
effective URL is resolved from CONFIGSERVER_URI (with a sensible default if
desired) instead of being fixed to localhost.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 9d5bce66-4dae-4eb7-89f6-12f749eac952
📒 Files selected for processing (2)
src/main/java/org/ticketing/queue/infrastructure/config/QueueSecurityConfig.javasrc/main/resources/application.yml
| @Configuration | ||
| public class QueueSecurityConfig { | ||
|
|
||
| // MVP 통합 테스트용 임시 SecurityConfig | ||
| @Bean | ||
| @Order(1) | ||
| public SecurityFilterChain queueFilterChain(HttpSecurity http) throws Exception { | ||
| return http | ||
| .securityMatcher("/**") | ||
| .csrf(AbstractHttpConfigurer::disable) | ||
| .formLogin(AbstractHttpConfigurer::disable) | ||
| .httpBasic(AbstractHttpConfigurer::disable) | ||
| .sessionManagement(session -> | ||
| session.sessionCreationPolicy(SessionCreationPolicy.STATELESS) | ||
| ) | ||
| .authorizeHttpRequests(auth -> auth | ||
| .anyRequest().permitAll() | ||
| ) | ||
| .build(); |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Verify whether permissive chain is profile-gated and whether other security chains/method-security exist.
rg -n --type=java '@Profile\(|@EnableMethodSecurity|@EnableWebSecurity|SecurityFilterChain|@Order\(' src/main/java
rg -n --type=java 'securityMatcher\("/\*\*"\)|anyRequest\(\)\.permitAll\(' src/main/javaRepository: 3s-ticketing/queue-service
Length of output: 740
🏁 Script executed:
# Check the full QueueSecurityConfig file
cat -n src/main/java/org/ticketing/queue/infrastructure/config/QueueSecurityConfig.javaRepository: 3s-ticketing/queue-service
Length of output: 1547
🏁 Script executed:
# Search for all SecurityFilterChain beans in the project to understand the overall security setup
rg -n --type=java 'public SecurityFilterChain' src/main/javaRepository: 3s-ticketing/queue-service
Length of output: 240
🏁 Script executed:
# Check if there are any Spring application properties or YAML configs that gate profiles
fd -e properties -e yml -e yaml src/main/resources | head -20Repository: 3s-ticketing/queue-service
Length of output: 448
🏁 Script executed:
# Search for any conditional annotations or profile-based configurations
rg -n --type=java '@ConditionalOnProperty|@ConditionalOnProfile|@Profile|spring\.config\.activate' src/main/javaRepository: 3s-ticketing/queue-service
Length of output: 52
🏁 Script executed:
# Correct fd syntax to find properties files
fd . 'src/main/resources' -e properties -e yml -e yamlRepository: 3s-ticketing/queue-service
Length of output: 147
🏁 Script executed:
# Search for any profile or conditional properties in config files
find src/main/resources -type f \( -name "*.properties" -o -name "*.yml" -o -name "*.yaml" \) 2>/dev/null | xargs grep -l "spring.config.activate\|spring.profiles" 2>/dev/null || echo "No profile config files found"Repository: 3s-ticketing/queue-service
Length of output: 100
🏁 Script executed:
# Also check if there are any other Java config classes that might conditionally disable/replace this config
rg -n --type=java 'QueueSecurityConfig|@ConditionalOnMissingBean|@Primary' src/main/javaRepository: 3s-ticketing/queue-service
Length of output: 189
Gate this permissive filter chain to test environments only; it currently allows unauthenticated access in all environments.
The QueueSecurityConfig class lacks a @Profile annotation despite the comment indicating it is temporary for MVP integration tests. With @Order(1), securityMatcher("/**"), and anyRequest().permitAll(), this is the only SecurityFilterChain bean in the codebase and will be active in production, effectively disabling authentication globally.
Add @Profile("test") to the class to restrict it to test environments, or remove it entirely if no longer needed.
Suggested patch direction
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
+import org.springframework.context.annotation.Profile;
...
`@Configuration`
+@Profile("test")
public class QueueSecurityConfig {🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In
`@src/main/java/org/ticketing/queue/infrastructure/config/QueueSecurityConfig.java`
around lines 11 - 29, The QueueSecurityConfig class currently exposes a
permissive SecurityFilterChain (securityMatcher("/**"),
anyRequest().permitAll()) in all environments; restrict it to tests by adding
the Spring profile annotation to the class (e.g., annotate QueueSecurityConfig
with `@Profile`("test")) or remove the entire class if it's no longer needed;
update imports to include org.springframework.context.annotation.Profile and
ensure the bean remains only active under the intended profile so production
authentication is not bypassed.
|
|
||
| config: | ||
| import: optional:configserver:${CONFIG_SERVER_URL:http://localhost:10002} | ||
| import: optional:configserver:http://localhost:10002 |
There was a problem hiding this comment.
Avoid hardcoded Config Server endpoint in shared config.
Line 6 pins the Config Server to http://localhost:10002, which will fail in non-local environments and removes deployment-time override flexibility.
Suggested patch
- import: optional:configserver:http://localhost:10002
+ import: optional:configserver:${CONFIG_SERVER_URL:http://localhost:10002}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| import: optional:configserver:http://localhost:10002 | |
| import: optional:configserver:${CONFIG_SERVER_URL:http://localhost:10002} |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/main/resources/application.yml` at line 6, Replace the hardcoded Config
Server URI in the import declaration so deployments can override it at runtime:
update the line that currently reads "import:
optional:configserver:http://localhost:10002" to reference an
environment/property placeholder (e.g. use ${CONFIGSERVER_URI} or a Spring
property) and keep the same "import: optional:configserver:" prefix so the
effective URL is resolved from CONFIGSERVER_URI (with a sensible default if
desired) instead of being fixed to localhost.
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/main/resources/application-docker.yml`:
- Line 42: The docker profile currently requires the
SPRING_KAFKA_BOOTSTRAP_SERVERS env var unconditionally which can cause
unresolved-placeholder startup failures; update the bootstrap-servers property
to provide a safe default using Spring’s property placeholder syntax (e.g.,
change bootstrap-servers: ${SPRING_KAFKA_BOOTSTRAP_SERVERS} to use a fallback
like ${SPRING_KAFKA_BOOTSTRAP_SERVERS:localhost:9092}) so the app can start when
the env var is missing; update the single property key bootstrap-servers
accordingly.
In `@src/main/resources/logback.xml`:
- Around line 49-61: The logging configuration file uses Spring Boot–specific
features like <springProfile> and converters (e.g., ColorConverter,
WhitespaceThrowableProxyConverter) so rename the resource file from logback.xml
to logback-spring.xml so Spring Boot will process these extensions and honor
profiles (e.g., the "docker" <springProfile> and the default/local profile)
without changing the file contents; after renaming, rebuild to verify the docker
profile activates and the JSON CONSOLE_JSON appender is used in that profile.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 19dc064c-0adf-4f05-b505-9ac320750815
📒 Files selected for processing (2)
src/main/resources/application-docker.ymlsrc/main/resources/logback.xml
|
|
||
| kafka: | ||
| bootstrap-servers: kafka:9092 | ||
| bootstrap-servers: ${SPRING_KAFKA_BOOTSTRAP_SERVERS} |
There was a problem hiding this comment.
Add a safe default for Kafka bootstrap servers to avoid unresolved-placeholder startup failure.
Line 42 currently requires SPRING_KAFKA_BOOTSTRAP_SERVERS unconditionally. If it’s missing, the docker profile can fail at startup before the app is usable.
🔧 Proposed fix
- bootstrap-servers: ${SPRING_KAFKA_BOOTSTRAP_SERVERS}
+ bootstrap-servers: ${SPRING_KAFKA_BOOTSTRAP_SERVERS:ticketing-kafka:9092}🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/main/resources/application-docker.yml` at line 42, The docker profile
currently requires the SPRING_KAFKA_BOOTSTRAP_SERVERS env var unconditionally
which can cause unresolved-placeholder startup failures; update the
bootstrap-servers property to provide a safe default using Spring’s property
placeholder syntax (e.g., change bootstrap-servers:
${SPRING_KAFKA_BOOTSTRAP_SERVERS} to use a fallback like
${SPRING_KAFKA_BOOTSTRAP_SERVERS:localhost:9092}) so the app can start when the
env var is missing; update the single property key bootstrap-servers
accordingly.
| <!-- 로컬: 텍스트, Docker: JSON --> | ||
| <springProfile name="default, local"> | ||
| <root level="INFO"> | ||
| <appender-ref ref="CONSOLE"/> | ||
| <appender-ref ref="FILE"/> | ||
| </root> | ||
| </springProfile> | ||
|
|
||
| <springProfile name="docker"> | ||
| <root level="INFO"> | ||
| <appender-ref ref="CONSOLE_JSON"/> | ||
| </root> | ||
| </springProfile> |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Verify current logging config wiring and whether both logback variants exist
fd -i 'logback*.xml' src/main/resources
rg -n -C3 'logging\.config|springProfile|logback-spring\.xml|logback\.xml' src/main/resourcesRepository: 3s-ticketing/queue-service
Length of output: 1084
🏁 Script executed:
#!/bin/bash
# Check if this is a Spring Boot project and verify dependencies
echo "=== Looking for Spring Boot dependencies ==="
find . -name "pom.xml" -o -name "build.gradle" | head -5
# Check pom.xml if it exists
if [ -f "pom.xml" ]; then
echo -e "\n=== Spring Boot dependency in pom.xml ==="
rg -i 'spring-boot' pom.xml | head -10
fi
# Check for application configuration files
echo -e "\n=== Application config files ==="
fd -i 'application.*\.(properties|yml|yaml)' src/
# Check if logging.config is specified anywhere
echo -e "\n=== Custom logging config references ==="
rg -i 'logging\.config' . --type properties --type yaml 2>/dev/null | head -10Repository: 3s-ticketing/queue-service
Length of output: 318
🏁 Script executed:
#!/bin/bash
# Verify Spring Boot's behavior with logback.xml vs logback-spring.xml
# by checking Spring Boot documentation references in code or comments
echo "=== Checking for any Spring Boot version info ==="
if [ -f "pom.xml" ]; then
rg -A2 'spring-boot-starter-parent|spring.boot.version' pom.xml
fi
# Check if there are any bootstrap or configuration files
echo -e "\n=== Bootstrap/Configuration setup ==="
find . -name "bootstrap*" -o -name "application-*" | grep -E '\.(properties|yml|yaml)$' | head -20Repository: 3s-ticketing/queue-service
Length of output: 203
🏁 Script executed:
#!/bin/bash
# Check Spring Boot version in build.gradle
echo "=== Spring Boot version ==="
rg -i 'spring.boot|springboot' build.gradle -A2 -B2
# Check what profiles are defined
echo -e "\n=== Active profiles in application.yml ==="
rg -i 'profiles|spring:' src/main/resources/application.yml -A5 -B2
echo -e "\n=== Application docker profile ==="
cat src/main/resources/application-docker.ymlRepository: 3s-ticketing/queue-service
Length of output: 2457
🏁 Script executed:
#!/bin/bash
# Check if the current logback.xml is actually being processed with springProfile
echo "=== Full logback.xml content ==="
cat src/main/resources/logback.xml
# Check for any test that might verify logging behavior
echo -e "\n=== Looking for log configuration tests ==="
find . -path '*/test/*' -name '*Log*' -o -path '*/test/*' -name '*Appender*' | head -10Repository: 3s-ticketing/queue-service
Length of output: 2498
Rename logback.xml to logback-spring.xml to enable <springProfile> processing.
The <springProfile> elements (lines 50 and 57) and Spring Boot–specific converters (ColorConverter, WhitespaceThrowableProxyConverter) are Spring Boot Logback extensions that require the file to be named logback-spring.xml. When named logback.xml, Spring Boot treats it as standard Logback and ignores these extensions. This silently breaks the profile-aware logging configuration: the docker profile will never activate, and both text and JSON appenders will be treated as standard elements.
Fix
Rename the file from src/main/resources/logback.xml to src/main/resources/logback-spring.xml. No content changes needed.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/main/resources/logback.xml` around lines 49 - 61, The logging
configuration file uses Spring Boot–specific features like <springProfile> and
converters (e.g., ColorConverter, WhitespaceThrowableProxyConverter) so rename
the resource file from logback.xml to logback-spring.xml so Spring Boot will
process these extensions and honor profiles (e.g., the "docker" <springProfile>
and the default/local profile) without changing the file contents; after
renaming, rebuild to verify the docker profile activates and the JSON
CONSOLE_JSON appender is used in that profile.
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@Dockerfile`:
- Around line 17-23: The final image runs as root because there is no USER
instruction; create a non-root user and switch to it before the ENTRYPOINT. In
the Dockerfile (around WORKDIR /app, COPY of app.jar, and ENTRYPOINT), add
commands to create a dedicated user/group (e.g., uid/gid 1000), chown the /app
directory and app.jar to that user, set a sane HOME, and add a USER instruction
to switch to that user so the jar (app.jar) runs without root privileges.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 69096148-a956-4984-9f06-61414389cea6
📒 Files selected for processing (2)
.gitignoreDockerfile
✅ Files skipped from review due to trivial changes (1)
- .gitignore
| FROM eclipse-temurin:17-jre | ||
|
|
||
| WORKDIR /app | ||
|
|
||
| COPY --from=build /app/build/libs/*.jar app.jar | ||
|
|
||
| ENTRYPOINT ["java", "-jar", "app.jar"] No newline at end of file |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Verify Dockerfiles that do not set a non-root USER
fd -i 'Dockerfile' -t f | while read -r f; do
echo "== $f =="
rg -n '^\s*USER\b' "$f" || echo "No USER instruction found"
doneRepository: 3s-ticketing/queue-service
Length of output: 113
🏁 Script executed:
cat -n DockerfileRepository: 3s-ticketing/queue-service
Length of output: 684
Run the runtime container as a non-root user.
Lines 17–23 define the final image but lack a USER instruction, causing the app to run as root. This weakens container isolation and violates security best practices.
Proposed fix
FROM eclipse-temurin:17-jre
WORKDIR /app
-
-COPY --from=build /app/build/libs/*.jar app.jar
+RUN useradd --system --create-home --uid 10001 appuser
+COPY --from=build /app/build/libs/*.jar /app/app.jar
+RUN chown -R appuser:appuser /app
+USER appuser
ENTRYPOINT ["java", "-jar", "app.jar"]📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| FROM eclipse-temurin:17-jre | |
| WORKDIR /app | |
| COPY --from=build /app/build/libs/*.jar app.jar | |
| ENTRYPOINT ["java", "-jar", "app.jar"] | |
| FROM eclipse-temurin:17-jre | |
| WORKDIR /app | |
| RUN useradd --system --create-home --uid 10001 appuser | |
| COPY --from=build /app/build/libs/*.jar /app/app.jar | |
| RUN chown -R appuser:appuser /app | |
| USER appuser | |
| ENTRYPOINT ["java", "-jar", "app.jar"] |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@Dockerfile` around lines 17 - 23, The final image runs as root because there
is no USER instruction; create a non-root user and switch to it before the
ENTRYPOINT. In the Dockerfile (around WORKDIR /app, COPY of app.jar, and
ENTRYPOINT), add commands to create a dedicated user/group (e.g., uid/gid 1000),
chown the /app directory and app.jar to that user, set a sane HOME, and add a
USER instruction to switch to that user so the jar (app.jar) runs without root
privileges.
2 participants
📎 관련 이슈
📌 작업 내용
✨ 변경 사항
📝 리뷰 포인트 (선택)
🧠 기타 참고 사항
(참고 문서, 스크린샷 등)
Summary by CodeRabbit
Chores
Operations