Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

🔧 Simplified configuration yml files #311

Conversation

devtobi
Copy link
Member

@devtobi devtobi commented Dec 6, 2024

Description

  • Simplified application yml files

Reference
Issues #304

Summary by CodeRabbit

  • New Features

    • Enhanced OAuth2 resource server configuration with a new user information endpoint.
    • Streamlined management endpoint exposure for better performance.
  • Bug Fixes

    • Removed obsolete error handling configurations to simplify error management.
  • Documentation

    • Improved organization of configuration files for clarity and maintainability.
  • Chores

    • Minor formatting adjustments made to various configuration files for consistency.
    • Repositioned sections in configuration files without altering existing functionality.

@devtobi devtobi requested a review from a team as a code owner December 6, 2024 11:23
Copy link

coderabbitai bot commented Dec 6, 2024

Walkthrough

The pull request introduces structural modifications to several configuration files within the refarch-gateway and refarch-integrations projects. Key changes include the removal and reorganization of properties in application.yml, application-test.yml, and various application-local.yml files. Notably, properties related to server configuration, error handling, and management endpoints have been adjusted or removed. The overall configuration structure has been simplified, and some sections have been repositioned without altering their content.

Changes

File Change Summary
refarch-gateway/src/main/resources/application.yml - Removed: spring.banner.location, spring.jackson.serialization.indent-output, server.port, management.endpoints.web.exposure.include values livenessState, readinessState
- Updated: management.endpoints.web.exposure.include to retain only health, info, prometheus
- Configured management.endpoint.health and management.endpoint.info to read_only
refarch-gateway/src/test/resources/application-test.yml - Reorganized: Moved wiremock section to the end of the file without content changes.
refarch-integrations/refarch-cosys-integration/refarch-cosys-integration-example/src/main/resources/application-example.yml - Reorganized: Moved refarch section within the file without content changes.
refarch-integrations/refarch-email-integration/refarch-email-integration-java-example/src/main/resources/application-local.yml - Added: Blank line after server section; no content changes.
refarch-integrations/refarch-email-integration/refarch-email-integration-rest-example/src/main/resources/application-local.yml - Added: server section reinstated with port: 8087.
refarch-integrations/refarch-s3-integration/refarch-s3-integration-rest/refarch-s3-integration-rest-service/src/main/resources/application-local.yml - Added: security.oauth2.resource.user-info-uri
- Reintroduced: server.port as 8086.
refarch-integrations/refarch-s3-integration/refarch-s3-integration-rest/refarch-s3-integration-rest-service/src/main/resources/application.yml - Removed: server.error.include-exception, server.error.include-stacktrace
- Updated: management.endpoints.web.exposure.include
- Added: management.endpoint.health.probes.enabled
- Restored: info section at the end of the file.

Possibly related PRs

  • 🔧 Added additional health check configuration #307: This PR modifies the management.endpoints.web.exposure.include section by adding health check configurations for livenessstate and readinessstate, which directly relates to the changes made in the main PR regarding the removal of these properties from the include list.

Suggested reviewers

  • DanielOber
  • simonhir

Poem

In the garden of code, we tidy and prune,
With changes so bright, like a warm afternoon.
Configs rearranged, like bunnies in play,
Simplified paths for a smoother way.
Hop along, dear friends, let’s celebrate this cheer,
For every small change brings the future near! 🐇✨


📜 Recent review details

Configuration used: .coderabbit.yaml
Review profile: ASSERTIVE

📥 Commits

Reviewing files that changed from the base of the PR and between c471d5b and caf7c52.

📒 Files selected for processing (2)
  • refarch-gateway/src/main/resources/application.yml (2 hunks)
  • refarch-gateway/src/test/java/de/muenchen/refarch/gateway/filter/GlobalRequestParameterPollutionFilterTest.java (1 hunks)
🧰 Additional context used
🪛 yamllint (1.35.1)
refarch-gateway/src/main/resources/application.yml

[error] 3-3: syntax error: found character '@' that cannot start any token

(syntax)

🔇 Additional comments (4)
refarch-gateway/src/main/resources/application.yml (3)

Line range hint 22-25: Security concern: Error details exposure needs to be environment-specific

The error configuration exposes message details in all environments, which could leak sensitive information in production:

  • include-message: always is set without environment-specific overrides
  • No profile-specific configurations found to disable it in production

Consider:

  1. Moving these settings to environment-specific files (e.g., application-local.yml)
  2. Using environment variables for dynamic configuration:
server:
  error:
-   include-message: always
+   include-message: ${ERROR_INCLUDE_MESSAGE:never}
    whitelabel:
      enabled: false
🧰 Tools
🪛 yamllint (1.35.1)

[error] 3-3: syntax error: found character '@' that cannot start any token

(syntax)


34-35: Improved security posture for management endpoints

Good changes:

  • Reduced attack surface by limiting exposed endpoints to essential ones
  • Consistent read_only access levels for all exposed endpoints

Line range hint 11-17: Verify CORS configuration security

The CORS configuration uses environment variables which is good practice, but let's verify:

  1. The security implications of allowing all headers (allowedHeaders: "*")
  2. The necessity of allowCredentials: true
✅ Verification successful

CORS configuration appears to be appropriately secured

The CORS configuration is well-designed and secure for the following reasons:

  • The /public/** routes only allow origin patterns defined via ALLOWED_ORIGINS_PUBLIC without credentials
  • The /clients/** routes have additional security with:
    • Restricted origins via ALLOWED_ORIGINS_CLIENTS environment variable
    • allowCredentials: true is necessary as these routes use JWT authentication
    • allowedHeaders: "*" is acceptable here as the routes are protected by OAuth2 and JWT validation

The documentation shows this is part of a well-architected gateway with:

  • OAuth2-based authentication
  • CSRF protection with configurable whitelist
  • Clear separation between public and authenticated routes
  • Environment-based configuration for origins, allowing deployment-specific security controls
🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Check for CORS-related environment variables in deployment configs
rg -l "ALLOWED_ORIGINS" 

# Check for any security documentation about CORS
fd -g "*security*.{md,txt}" -t f | xargs rg -l "CORS"

Length of output: 154


Script:

#!/bin/bash
# Let's check the README for any CORS configuration documentation
cat refarch-gateway/README.md

# Let's also check for any CORS-related code in the codebase
rg -A 5 -B 5 "allowedHeaders|allowCredentials|ALLOWED_ORIGINS" 

Length of output: 9198

🧰 Tools
🪛 yamllint (1.35.1)

[error] 3-3: syntax error: found character '@' that cannot start any token

(syntax)

refarch-gateway/src/test/java/de/muenchen/refarch/gateway/filter/GlobalRequestParameterPollutionFilterTest.java (1)

41-41: Verify error response format consistency

The assertion format has been updated to remove spaces in the JSON. Let's verify this matches the actual response format from the error handler.

✅ Verification successful

Based on the gathered information, I can now generate the final response:

Assertion format is correct

The test assertion "\"message\":\"parameter pollution\"" is correctly formatted as the Spring Boot error handling (configured with server.error.include-message: always) generates JSON responses without spaces. The test verifies the exact format that would be returned by the default error handling mechanism when the ParameterPollutionException is thrown.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for error response format configuration or implementation
ast-grep --pattern 'class $_ implements ErrorWebExceptionHandler {
  $$$
}'

# Check for other tests that verify error responses
rg -l "isEqualTo\(HttpStatus\.BAD_REQUEST\)" -t java

Length of output: 346


Script:

#!/bin/bash
# Let's check the actual error response format in the test files
rg "message.*parameter pollution" -A 5 -B 5 refarch-gateway/src/test/java/de/muenchen/refarch/gateway/filter/GlobalRequestParameterPollutionFilterTest.java

# Also check the implementation of error handling
fd "Global.*Filter.java" --exec cat {}

Length of output: 7348


Script:

#!/bin/bash
# Let's check the ParameterPollutionException to see how the error message is formatted
rg -t java "class ParameterPollutionException" -A 10

Length of output: 714


Script:

#!/bin/bash
# Let's check for any global exception handlers that might format the error response
rg -t java "implements (WebExceptionHandler|ErrorWebExceptionHandler)" -A 5

Length of output: 77


Script:

#!/bin/bash
# Let's check for any classes that handle exceptions or error responses
rg -t java "class.*Exception.*Handler" -A 5

# Also check for any configuration related to error handling
fd "application.yml" --exec cat {}

Length of output: 3606


Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

❤️ Share
🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Generate unit testing code for this file.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai generate unit testing code for this file.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and generate unit testing code.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

@github-actions github-actions bot added Component: API-Gateway Issues regarding the API Gateway Component: Integrations Issues regarding the Integrations Type: Maintenance The issue contains maintenance work. labels Dec 6, 2024
Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 5

🧹 Outside diff range comments (5)
refarch-integrations/refarch-cosys-integration/refarch-cosys-integration-example/src/main/resources/application-example.yml (2)

Line range hint 1-19: Consider using placeholder credentials in example configuration

While this is an example configuration, using literal values like "local" and "client_secret" could lead to security issues if accidentally used in production. Consider using obvious placeholder values.

-            client-id: local
-            client-secret: client_secret
+            client-id: YOUR_CLIENT_ID_HERE
+            client-secret: YOUR_CLIENT_SECRET_HERE
🧰 Tools
🪛 yamllint (1.35.1)

[error] 36-36: no new line character at the end of file

(new-line-at-end-of-file)


Security Configuration Review Required

Based on the verification results, several security concerns need attention:

  1. This appears to be an example configuration file (application-example.yml), but it contains hardcoded sensitive values:

    • Client secrets are plaintext (client_secret)
    • Example URLs use insecure HTTP (http://localhost:8086)
    • Example domain names are used (example.com)
  2. No production or other environment-specific configurations were found, suggesting this example file might be used as a template.

  3. While enable-security: true is correctly set, the presence of hardcoded credentials in a version-controlled example file poses a security risk.

Recommendations:

  • Replace hardcoded secrets with placeholders (e.g., ${CLIENT_SECRET})
  • Document the required environment variables
  • Ensure all URLs use HTTPS in non-local environments
  • Create separate, secure configuration files for different environments
🔗 Analysis chain

Line range hint 1-36: Verify security settings across environments

Please ensure that:

  1. The SSO issuer URI is correctly configured for different environments
  2. The document-storage-url is properly secured in production
  3. enable-security flag is always true in non-local environments

Let me gather more information about the security configurations across different environments.


Let me check for the presence of different environment-specific configuration files and their security settings.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Check for potential security misconfigurations across yml files
echo "Checking for security configurations across environments..."
rg -l "enable-security:\s*(false|no|off)" --type yaml
rg -l "localhost" --type yaml
rg -l "example\.com" --type yaml

Length of output: 1038


Script:

#!/bin/bash
# Check content of application yml files for security patterns
echo "Checking application-example.yml..."
rg "enable-security|client-secret|localhost|example\.com" refarch-integrations/refarch-cosys-integration/refarch-cosys-integration-example/src/main/resources/application-example.yml

echo -e "\nChecking other application yml files..."
fd "application.*\.yml" --type f --exec rg -l "enable-security:\s*true" {}

Length of output: 971


Script:

#!/bin/bash
# Check for different environment configurations
echo "Checking for environment-specific configurations in the cosys integration..."
fd "application-.*\.yml" refarch-integrations/refarch-cosys-integration/

echo -e "\nChecking content of all environment configurations..."
fd "application-.*\.yml" refarch-integrations/refarch-cosys-integration/ --exec cat {}

Length of output: 1624

🧰 Tools
🪛 yamllint (1.35.1)

[error] 36-36: no new line character at the end of file

(new-line-at-end-of-file)

refarch-integrations/refarch-email-integration/refarch-email-integration-java-example/src/main/resources/application-local.yml (1)

Line range hint 1-22: Consider externalizing sensitive credentials.

The configuration contains hardcoded credentials for both mail and S3 services. While this is acceptable for local development, consider:

  1. Using environment variables or external secret management
  2. Adding a comment indicating this is for local development only
  3. Documenting the required environment variables in README

Example approach:

spring:
  mail:
    host: localhost
    port: 1025
-    username: [email protected]
-    password: secret
+    username: ${MAIL_USERNAME:[email protected]}
+    password: ${MAIL_PASSWORD:secret}

server:
  port: 8087

refarch:
  s3:
    bucket-name: test-bucket
-    access-key: minio
-    secret-key: Test1234
+    access-key: ${S3_ACCESS_KEY:minio}
+    secret-key: ${S3_SECRET_KEY:Test1234}
    url: http://localhost:9000
refarch-integrations/refarch-email-integration/refarch-email-integration-rest-example/src/main/resources/application-local.yml (1)

Line range hint 1-20: Consider using environment variables for sensitive information

Even in local development configurations, it's recommended to externalize sensitive information like credentials and secrets using environment variables or a secure vault solution.

Consider refactoring sensitive configurations like this:

spring:
  mail:
    host: localhost
    port: 1025
-    username: [email protected]
-    password: secret
+    username: ${MAIL_USERNAME:[email protected]}
+    password: ${MAIL_PASSWORD:secret}
  security:
    oauth2:
      client:
        registration:
          s3:
-            client-id: local
-            client-secret: client_secret
+            client-id: ${OAUTH_CLIENT_ID:local}
+            client-secret: ${OAUTH_CLIENT_SECRET:client_secret}
refarch-gateway/src/main/resources/application.yml (1)

Line range hint 9-17: Review CORS configuration security

The CORS configuration uses environment variables which is good practice, but consider:

  1. Using more specific patterns instead of "*" for allowedHeaders
  2. Documenting the expected format of ALLOWED_ORIGINS_PUBLIC and ALLOWED_ORIGINS_CLIENTS

Consider refining the configuration like this:

        cors-configurations:
          '[/public/**]':
            allowedOriginPatterns: ${ALLOWED_ORIGINS_PUBLIC}
          '[/clients/**]':
            allowedOriginPatterns: ${ALLOWED_ORIGINS_CLIENTS}
-           allowedHeaders: "*"
+           allowedHeaders: 
+             - Authorization
+             - Content-Type
+             - X-Requested-With
            allowCredentials: true
🧰 Tools
🪛 yamllint (1.35.1)

[error] 3-3: syntax error: found character '@' that cannot start any token

(syntax)

📜 Review details

Configuration used: .coderabbit.yaml
Review profile: ASSERTIVE

📥 Commits

Reviewing files that changed from the base of the PR and between 8f99d19 and 2d693f6.

📒 Files selected for processing (7)
  • refarch-gateway/src/main/resources/application.yml (2 hunks)
  • refarch-gateway/src/test/resources/application-test.yml (1 hunks)
  • refarch-integrations/refarch-cosys-integration/refarch-cosys-integration-example/src/main/resources/application-example.yml (1 hunks)
  • refarch-integrations/refarch-email-integration/refarch-email-integration-java-example/src/main/resources/application-local.yml (1 hunks)
  • refarch-integrations/refarch-email-integration/refarch-email-integration-rest-example/src/main/resources/application-local.yml (1 hunks)
  • refarch-integrations/refarch-s3-integration/refarch-s3-integration-rest/refarch-s3-integration-rest-service/src/main/resources/application-local.yml (1 hunks)
  • refarch-integrations/refarch-s3-integration/refarch-s3-integration-rest/refarch-s3-integration-rest-service/src/main/resources/application.yml (2 hunks)
🧰 Additional context used
🪛 yamllint (1.35.1)
refarch-gateway/src/test/resources/application-test.yml

[error] 37-37: no new line character at the end of file

(new-line-at-end-of-file)

refarch-integrations/refarch-cosys-integration/refarch-cosys-integration-example/src/main/resources/application-example.yml

[error] 36-36: no new line character at the end of file

(new-line-at-end-of-file)

refarch-integrations/refarch-s3-integration/refarch-s3-integration-rest/refarch-s3-integration-rest-service/src/main/resources/application-local.yml

[error] 21-21: no new line character at the end of file

(new-line-at-end-of-file)

refarch-integrations/refarch-s3-integration/refarch-s3-integration-rest/refarch-s3-integration-rest-service/src/main/resources/application.yml

[error] 40-40: syntax error: found character '@' that cannot start any token

(syntax)

refarch-gateway/src/main/resources/application.yml

[error] 3-3: syntax error: found character '@' that cannot start any token

(syntax)

🔇 Additional comments (10)
refarch-gateway/src/test/resources/application-test.yml (1)

Line range hint 1-32: Verify the SSO configuration for test environment.

The configuration uses production SSO URLs (sso.muenchen.de) with a test realm. While this works for initializing the Spring context, it might be better to use test-specific SSO endpoints.

Let's check if there are any test-specific SSO configurations in other files:

🧰 Tools
🪛 yamllint (1.35.1)

[error] 37-37: no new line character at the end of file

(new-line-at-end-of-file)

refarch-integrations/refarch-email-integration/refarch-email-integration-java-example/src/main/resources/application-local.yml (1)

7-10: LGTM! Clean formatting improvements.

The added blank lines improve readability by logically separating configuration sections.

refarch-integrations/refarch-s3-integration/refarch-s3-integration-rest/refarch-s3-integration-rest-service/src/main/resources/application-local.yml (2)

8-11: LGTM! Well-structured OAuth2 configuration.

Good use of template variable for user-info-uri, maintaining DRY principles by referencing the existing issuer-uri.


13-15: LGTM! Clear server port configuration.

The server port configuration is clearly defined and aligns with the PR's goal of simplifying configuration files.

refarch-integrations/refarch-s3-integration/refarch-s3-integration-rest/refarch-s3-integration-rest-service/src/main/resources/application.yml (3)

23-24: LGTM! Enhanced health monitoring.

Good addition of health probes configuration, which provides better container health monitoring capabilities.


38-44: LGTM! Well-structured application info.

The info section is properly restored with Maven property placeholders. Note: The YAML lint warning about @ symbols can be safely ignored as these are valid Maven property placeholders.

🧰 Tools
🪛 yamllint (1.35.1)

[error] 40-40: syntax error: found character '@' that cannot start any token

(syntax)


17-17: Verify impact of removed management endpoints.

The removal of livenessstate and readinessstate from exposed endpoints might affect monitoring systems. Please verify that:

  1. These endpoints are not required by your monitoring stack
  2. The health endpoint provides sufficient monitoring capabilities
refarch-integrations/refarch-email-integration/refarch-email-integration-rest-example/src/main/resources/application-local.yml (1)

22-24: LGTM: Server port configuration

The addition of the server port configuration is clear and follows the standard Spring Boot configuration format.

refarch-gateway/src/main/resources/application.yml (2)

2-3: LGTM: Project metadata configuration

The use of Maven property placeholders for project metadata is a good practice for maintaining consistency between pom.xml and application configuration.

🧰 Tools
🪛 yamllint (1.35.1)

[error] 3-3: syntax error: found character '@' that cannot start any token

(syntax)


35-35: Verify impact of removed management endpoints

The removal of livenessState and readinessState from exposed endpoints might affect container orchestration health checks.

Let's check if these endpoints are used in any Kubernetes configurations:

✅ Verification successful

Removal of livenessState and readinessState endpoints is safe

The changes to management endpoints are safe because:

  1. The livenessState and readinessState are still enabled in the configuration (management.health.livenessstate.enabled: true and management.health.readinessstate.enabled: true)
  2. The health endpoint is still exposed (include: health)
  3. Kubernetes probes in docker-compose.yml use basic health check URLs that don't depend on these specific endpoints
  4. Spring Boot's /health endpoint automatically includes liveness and readiness information when the probes are enabled
🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for potential health check configurations
rg -l 'livenessProbe|readinessProbe' --type yaml

Length of output: 50


Script:

#!/bin/bash
# Let's try a broader search for deployment configurations and health check patterns
fd -e yaml -e yml | xargs grep -l -i "health\|probe\|liveness\|readiness"

Length of output: 294


Script:

#!/bin/bash
# Let's examine the content of these files to understand health check configurations
echo "=== Gateway application.yml ==="
cat refarch-gateway/src/main/resources/application.yml

echo -e "\n=== Docker Compose ==="
cat stack/docker-compose.yml

Length of output: 4751

simonhir
simonhir previously approved these changes Dec 6, 2024
Copy link
Member

@simonhir simonhir left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🧹 Outside diff range comments (1)
refarch-gateway/src/main/resources/application.yml (1)

Line range hint 1-70: Overall configuration simplification achieved.

The changes successfully simplify the configuration by:

  • Removing non-essential properties (banner.location, jackson serialization)
  • Maintaining a clean hierarchical structure
  • Retaining critical functionality (security, management endpoints)

However, consider documenting the rationale for removing certain properties in the PR description to help with future maintenance.

🧰 Tools
🪛 yamllint (1.35.1)

[error] 3-3: syntax error: found character '@' that cannot start any token

(syntax)

📜 Review details

Configuration used: .coderabbit.yaml
Review profile: ASSERTIVE

📥 Commits

Reviewing files that changed from the base of the PR and between 2d693f6 and c471d5b.

📒 Files selected for processing (2)
  • refarch-gateway/src/main/resources/application.yml (3 hunks)
  • refarch-gateway/src/test/java/de/muenchen/refarch/gateway/filter/GlobalRequestParameterPollutionFilterTest.java (1 hunks)
🧰 Additional context used
🪛 yamllint (1.35.1)
refarch-gateway/src/main/resources/application.yml

[error] 3-3: syntax error: found character '@' that cannot start any token

(syntax)

🔇 Additional comments (4)
refarch-gateway/src/test/java/de/muenchen/refarch/gateway/filter/GlobalRequestParameterPollutionFilterTest.java (2)

41-41: LGTM! Enhanced security test coverage.

The improved assertion now verifies both the error message and the specific exception type, providing more thorough validation of the parameter pollution security feature.


41-41: Verify error response format configuration.

Since the PR includes changes to error handling configuration (removal of include-exception property), let's verify that the expected error response format remains consistent.

✅ Verification successful

Error response format is correctly configured and consistent

The verification shows that:

  • The application.yml explicitly has include-exception: true in the server error configuration
  • The test assertion is consistent with this configuration as it checks for the exception class in the response
  • This is the only test in the codebase that relies on exception details in the response
  • The ParameterPollutionException is properly integrated in the filter and exception handling flow
🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check error handling configuration in application yml files

# Search for error handling related configuration
echo "Checking error handling configuration in application yml files:"
fd -e yml -e yaml | xargs rg -l "include-exception|error|exception"

# Search for any other tests relying on error response format
echo -e "\nChecking other tests that may rely on error response format:"
rg -t java "expectBody.*contains.*exception" -g "**/*Test.java"

Length of output: 603


Script:

#!/bin/bash
# Let's check the content of the application.yml files to see error handling configuration
echo "Content of gateway application.yml:"
cat refarch-gateway/src/main/resources/application.yml

# Let's also check for any error response related tests or configurations
echo -e "\nSearching for error response related patterns in tests:"
rg "assertThat.*contains.*exception|assertTrue.*contains.*exception|assertResponse.*exception" -g "**/*Test.java"

# Let's specifically look for ParameterPollutionException usage
echo -e "\nSearching for ParameterPollutionException usage:"
rg "ParameterPollutionException" --type java

Length of output: 3312

refarch-gateway/src/main/resources/application.yml (2)

2-3: LGTM! Clean hierarchical structure.

The application name configuration is properly nested under the application section, following Spring Boot's configuration best practices.

🧰 Tools
🪛 yamllint (1.35.1)

[error] 3-3: syntax error: found character '@' that cannot start any token

(syntax)


36-36: Verify health probe endpoint configuration consistency.

There appears to be a potential inconsistency:

  • Health probes (livenessstate and readinessstate) are enabled in the management.health section
  • However, these endpoints are not included in the management.endpoints.web.exposure.include list

This might prevent the health probe endpoints from being accessible even though they are enabled.

Let's check the Spring Boot documentation version and other services for consistent health probe configurations:

refarch-gateway/src/main/resources/application.yml Outdated Show resolved Hide resolved
Copy link
Member

@simonhir simonhir left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@devtobi devtobi merged commit a2e2b7d into main Dec 6, 2024
14 checks passed
@devtobi devtobi deleted the maint/304-maintenance-clean-up-applicationyml-by-removing-properties-which-are-set-to-default-values branch December 6, 2024 13:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Component: API-Gateway Issues regarding the API Gateway Component: Integrations Issues regarding the Integrations Type: Maintenance The issue contains maintenance work.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Maintenance] Clean up application.yml by removing properties which are set to default values
2 participants