feat: complete ssrf-guard demo matrix (httpclient5-demo + native-image-demo)#61
Merged
Merged
Conversation
…demo Two new demos closing out the ssrf-guard module coverage: ssrf-guard-httpclient5-demo --------------------------- The only ssrf-guard module without a runnable demo before this. Apache HttpClient 5 plugs the SSRF policy in at DNS-resolution time rather than URL-parse time — a different shape from the other client demos. - SafeDnsResolver (DnsResolver SPI): rejects hosts outside the whitelist, filters private/loopback/link-local/cloud-metadata IPs out of the resolved set. The InetAddress[] it returns is what HttpClient hands to Socket.connect(), closing the TOCTOU window. - SafeRedirectStrategy (RedirectStrategy SPI): same DNS gate runs on every redirect hop. - The module ships its own Spring autoconfig (SsrfGuardHttpClient5AutoConfiguration), so the demo's main() needs zero wiring code. Outside Spring, five lines on HttpClients.custom(). The README acknowledges the trade-off honestly: this approach doesn't do URL-parse-time gates (scheme restriction, userinfo rejection) but does close all the practical attack vectors at the resolver, and the TOCTOU-closing property is the main selling point. ssrf-guard-native-image-demo ---------------------------- End-to-end proof that ssrf-guard 3.1.0's RuntimeHintsRegistrar entries let a Spring Boot app `./gradlew nativeCompile` without writing any reflect-config.json for our types. - Pulls kr.devslab:ssrf-guard:3.1.0 (the meta artifact — -restclient + -httpclient5 + -core, hints come along). - Applies org.graalvm.buildtools.native plugin. - Exposes /fetch + /attacks (a 12-pattern catalog). - Surfaces "runtime": "jvm" vs "graalvm-native" so visual inspection confirms which build you're hitting. CI builds JVM mode only (native-image is too slow / memory-heavy for every PR). README documents the local verification flow: - ./gradlew processAot (fast ~10s) to verify hints register - ./gradlew nativeCompile (3-8 min) to produce a working binary Top-level README + README.ko.md updated with rows for both new demos. Verified: ./gradlew build passes for both demos in JVM mode against the live Maven Central kr.devslab:ssrf-guard*:3.1.0 artifacts (httpclient5 build 33s, native-image build 1m21s).
Same Windows-clone gotcha that bit ssrf-guard-langchain4j-demo earlier (devslab-examples/#52 → fixup commit 0971c1b). The gradlew scripts in ssrf-guard-httpclient5-demo and ssrf-guard-native-image-demo were committed as 100644 (no execute bit), so Linux CI failed with: /home/runner/.../gradlew: Permission denied Process completed with exit code 126. Re-stage with chmod=+x → 100755. No content change.
4 tasks
jlc488
added a commit
that referenced
this pull request
May 23, 2026
CI failed with `./gradlew: Permission denied` (exit 126) on all three new demos. The agents created the wrappers via `cp -r` on Windows, where the filesystem doesn't track executable bits, so git stored them as 0644. Linux CI runners then refused to execute them. `git update-index --chmod=+x` flips the index mode to 100755 without changing file content. Same fix as #61 used (commit 2dbf4a4).
jlc488
added a commit
that referenced
this pull request
May 25, 2026
…stcontainers IT (#62) * feat: add api-log demo set (jpa + mybatis + r2dbc) with PostgreSQL Testcontainers IT Covers all three persistence backends of the api-log starter (kr.devslab:api-log-{jpa,mybatis,r2dbc}:3.0.0) so a reader can pick the demo that matches their stack and `./gradlew bootRun` immediately. ## Demos added api-log-jpa-demo/ Spring MVC + JPA + Postgres (blocking) api-log-mybatis-demo/ Spring MVC + MyBatis + Postgres (blocking) api-log-r2dbc-demo/ WebFlux + R2DBC + Postgres (reactive) ## Common design — self-loopback Each demo exposes three controllers in the same app: /upstream/widgets/{id} the "service being called" — returns a fake Widget, with id=999 forcing a 5xx to exercise the error path /client/widgets/{id} calls upstream via RestApiClientUtil (or ReactiveApiClientUtil for r2dbc) so the call gets logged into api_log /client/widgets/with-request-id/{id} same shape but passes an explicit requestId via the core send(HttpMethod, ApiRequest) overload — demonstrates the retry-correlation API /api-log/recent reads the api_log table (top 20 by timestamp DESC) /api-log/by-request/{rid} reads all rows for one requestId (lifecycle: INITIATED → SUCCESS / ERROR) /api-log/by-event/{type} reads all rows for one event type Self-loopback means no external dep — `docker compose up -d db && ./gradlew bootRun && curl localhost:8080/client/widgets/123` is the full demo. Reader can immediately see INITIATED + SUCCESS pairs in /api-log/recent after the async event listener flushes. ## Tests — Testcontainers + @Serviceconnection Each demo ships an integration test (ApiLogLifecycleIT) that spins up postgres:16-alpine via Testcontainers, makes real HTTP self-loopback calls (RestClient.create / TestRestTemplate / WebTestClient depending on the demo's stack), and asserts on the api_log rows that the async listener writes. Awaitility polls past the listener's async window. Five tests per demo: 1. happy GET path → INITIATED + SUCCESS in api_log 2. error path (id=999) → INITIATED + ERROR 3. POST body preserved in api_log.payload (JSONB) 4. explicit requestId correlation via /with-request-id/{id} 5. schema initialized on boot (table exists, query succeeds) 15 IT tests total across the three demos. CI builds them automatically (the workflow's detect step picks up new demos by the presence of build.gradle.kts — no workflow edits needed). ## Backend-specific notes JPA: - spring-boot-starter-data-jpa + api-log-jpa - Reader uses ApiLogRepository (the starter publishes it as a Spring Data repository — extends JpaRepository<ApiLogEntity, Long>) - spring.jpa.hibernate.ddl-auto=none — api-log starter's ApiLogJpaSchemaInitializer creates the api_log table itself (api.log.schema.management=BUILTIN) MyBatis: - mybatis-spring-boot-starter:4.0.1 + api-log-mybatis - Reader uses the bundled ApiLogMapper for findByRequestId, plus a custom ApiLogQueryMapper (xml) for findRecent / findByEvent since the starter's mapper doesn't expose those - @MapperScan scoped to the demo package only (the starter's mapper is registered by its own auto-config — scanning it twice conflicts) R2DBC: - spring-boot-starter-webflux + spring-boot-starter-data-r2dbc + api-log-r2dbc - Reader uses DatabaseClient (not a Spring Data R2DBC repository — the api-log r2dbc backend doesn't ship one, keeping its dep footprint minimal). Cast JSONB columns to ::text so they bind cleanly to String fields on a public ApiLogView record. - Schema initializer is opt-in via api.log.r2dbc.schema.enabled=true (separate property from the JDBC backends because reactive init runs on ConnectionFactory not DataSource — per ApiLogProperties javadoc) - Both r2dbc-postgresql AND jdbc postgresql drivers in the build — the latter is what Testcontainers' @Serviceconnection prefers for rewiring the connection. ## Root README updates Added an "### api-log" section after the ssrf-guard section in both README.md and README.ko.md, with the three new demos linked from a single table. Matches the existing table convention (Maven Central shields.io badge with verbose label) — a follow-up that strips the labels to the default "Maven Central" form (per devslab-examples#59) would touch all rows at once. ## Sibling work in flight devslab-examples#61 adds two more ssrf-guard demos (ssrf-guard-httpclient5-demo + ssrf-guard-native-image-demo) on a parallel branch. The two PRs are independent — they touch different directories. README.md will conflict on the section ordering after both land; whichever merges second rebases. * fix(api-log demos): mark gradlew executable in git index CI failed with `./gradlew: Permission denied` (exit 126) on all three new demos. The agents created the wrappers via `cp -r` on Windows, where the filesystem doesn't track executable bits, so git stored them as 0644. Linux CI runners then refused to execute them. `git update-index --chmod=+x` flips the index mode to 100755 without changing file content. Same fix as #61 used (commit 2dbf4a4). * fix(api-log demos): downgrade to Spring Boot 3.5.6 baseline CI failed with BeanTypeDeductionException -> ClassNotFoundException during Spring context load on all three demo ITs. Root cause: api-log 3.0.0 is built against Spring Boot 3.5.6 per the Spring-major-aligned versioning policy (devslab-kr/.github/.github/VERSIONING.md — lib major = SB major, so api-log 3.x = SB3 line). My demos were on SB4.0.6 and the runtime classpath had api-log's compiled bytecode referencing SB3.5 classes that don't exist in SB4 — gradle resolution upgraded the spring-boot-* artifacts to 4.0.6 but didn't paper over the API drift. Changes per demo (build.gradle.kts): Plugin 4.0.6 -> 3.5.6 Test starters removed SB4-only -webmvc-test / -webflux-test / -resttestclient modules (MockMvc / WebTestClient / TestRestTemplate all ship in plain spring-boot-starter-test on SB3) Testcontainers BOM removed (relying on Spring Boot 3.5.6's managed Testcontainers versions — same approach as easy-paging-postgres-demo + easy-paging-reactive-demo) Testcontainers names testcontainers-postgresql -> postgresql, testcontainers-junit-jupiter -> junit-jupiter (Testcontainers 1.x naming convention, what SB3 BOM pins) MyBatis starter mybatis-spring-boot-starter:4.0.1 -> :3.0.4 (SB3-compatible line; matches what PageHelper + Spring Boot 3 BOM expects) R2DBC extras added testcontainers:r2dbc (the R2DBC @Serviceconnection bridge for SB3 — matches easy-paging-reactive-demo) Unchanged api-log 3.0.0 deps, awaitility 4.2.2, R2DBC + JDBC postgres drivers, dependency-management 1.1.7, JDK 21 toolchain, junit-platform-launcher Changes per IT (imports): PostgreSQLContainer org.testcontainers.postgresql.PostgreSQLContainer -> org.testcontainers.containers.PostgreSQLContainer (Testcontainers 1.x class location) Container generic raw PostgreSQLContainer -> PostgreSQLContainer<?> field type + new PostgreSQLContainer<>("...") (1.x self-typed generic, diamond form) @AutoConfigureWebTestClient (r2dbc only) org.springframework.boot.webtestclient.autoconfigure -> org.springframework.boot.test.autoconfigure.web.reactive TestRestTemplate (mybatis only) org.springframework.boot.resttestclient -> org.springframework.boot.test.web.client @LocalServerPort no change (lives at org.springframework.boot.test.web.server in both SB3.5.6 and SB4 — spec mid-flight said otherwise, agents caught it via compile error) Test logic itself unchanged (5 tests × 3 demos = 15 IT tests). Main- source files (controllers, Widget record, ApiLogReader/View, MyBatis mapper xml, application.yml, docker-compose.yml, READMEs) all source-compatible between SB3 and SB4 — only build pin + a handful of test imports needed to move. Compile verified clean on all 3 demos. Awaiting CI for the runtime path. Follow-up: once api-log ships a 4.x line (the VERSIONING.md policy schedules it for whenever the project decides to add SB4 support), add api-log-{jpa,mybatis,r2dbc}-sb4-demo siblings — same pattern as the easy-paging dual-line setup. * fix(api-log demos): self-loopback URL uses runtime local.server.port The 3 CI test failures (happyGet / postBody / explicitRequestId — all the success-path tests) were a real bug, not a flake: ClientController read `${api-log-demo.upstream-base-url}` which expanded to `http://localhost:8080` at @value injection time. The integration test boots on RANDOM_PORT — e.g. 54321 — so: Test → http://localhost:54321/client/widgets/123 OK ClientController → http://localhost:8080/upstream/widgets/123 CONN REFUSED → 500 errorPath and schemaInit passed for the wrong reason — errorPath asserts an ERROR row shows up regardless of cause (connection-refused counts), and schemaInit never touches HTTP. Fix: don't hardcode the port in config. ClientController now injects Environment and builds the upstream URL at request time from `local.server.port` (which Spring Boot sets for BOTH bootRun and RANDOM_PORT after the embedded server binds). One code path, one behaviour, no test-specific override. Removed `api-log-demo.upstream-base-url` from all 3 application.yml since nothing reads it anymore; comment now points users at ClientController for the "swap upstream URL for production" instruction. All three demos compile clean. The bug existed in the original SB4 version too — only surfaced after the SB3 downgrade got past the ContextLoader exception and tests could actually run. * chore(api-log demos): bump 3.0.0 -> 3.0.1 (HTTP client Content-Type + PATCH fixes) api-log v3.0.1 published to Maven Central (devslab-kr/api-log#4 + #5 merged, tag pushed, release workflow succeeded at 16:39Z, all four artifacts indexed). 3.0.1 fixes two bugs in RestApiClientUtil / ReactiveApiClientUtil that the previous PR #62 CI runs surfaced: 1. Content-Type missing on POST/PUT/PATCH body -> upstream returned 415/500 (the postBodyIsPreservedInPayloadColumn failures across all three demos). 2. PATCH method unsupported because SimpleClientHttpRequestFactory wraps java.net.HttpURLConnection (which rejects PATCH). Bump scope: one line per demo build.gradle.kts (well, two — core + backend), three demos = 6 lines. No source changes needed — the bugs were entirely in the starter, the demo code was already calling the right APIs. Expecting all 15 IT tests (5 per demo) to pass on this run now that the starter is fixed.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Two new demos closing out the ssrf-guard module coverage on devslab-examples — every module published to Maven Central now has a runnable demo or a transitive home in one.
ssrf-guard-httpclient5-demoDnsResolver+RedirectStrategyplug-in points, withSafeDnsResolverclosing the TOCTOU window between URL validation andSocket.connect().ssrf-guard-native-image-demoRuntimeHintsRegistrarentries let a Spring Boot app./gradlew nativeCompilesuccessfully — no consumer-sidereflect-config.jsonrequired.What changes
+ ssrf-guard-httpclient5-demo/(16 files) — full Spring Boot scaffold mirroringssrf-guard-okhttp-demo, smoke tests for the 3 DNS-gate block paths+ ssrf-guard-native-image-demo/(16 files) — Spring Boot +org.graalvm.buildtools.nativeplugin, 12-pattern attack catalog, JVM-mode smoke tests, README documenting thenativeCompileworkflowREADME.md+README.ko.md— new rows for both demos, with badgesVerification
Both demos
./gradlew build(incl. tests) passes locally against live Maven Central artifacts:ssrf-guard-httpclient5-demossrf-guard-native-image-demoNative-image build (
./gradlew nativeCompile) is not run in CI — it's documented as a local verification step for native-image users. CI's JVM build exercises the sameprocessAotcodegen path indirectly via the test suite.Coverage matrix (now complete)
ssrf-guard-restclient/-resttemplate/-webclientssrf-guard-demo(combined 3-in-1)ssrf-guard-feignssrf-guard-feign-demossrf-guard-okhttpssrf-guard-okhttp-demossrf-guard-jdkhttpssrf-guard-jdkhttp-demossrf-guard-springaissrf-guard-springai-demossrf-guard-langchain4jssrf-guard-langchain4j-demossrf-guard-httpclient5ssrf-guard-httpclient5-demo(new)ssrf-guardmeta + AOT hintsssrf-guard-native-image-demo(new)ssrf-guard-core/-llmTest plan
./gradlew buildpasses for both demos./gradlew bootRunon either demo and try thecurlsnippets from the READMENote on parallel branch work
feat/api-log-demosis a separate parallel effort (api-log demos —api-log-jpa-demo,-mybatis-demo,-r2dbc-demoshow up as untracked when both branches are pulled together). This PR scopes only the ssrf-guard demos and intentionally doesn't touch api-log demos.