requestshield 2.1.0-stg.427 → 2.2.0-qat.440

package/config/.env.qat

@@ -0,0 +1,7 @@
+# Public QAT settings for the QAT npm release and source runner. Never add secrets.
+API_URL=https://management-api-qat.intellifend.ai
+CHALLENGE_URL=https://challenge-dev.intellifend.ai
+DOCS_URL=https://docs-qat.intellifend.ai
+OAUTH_ISSUER=https://auth-qat.intellifend.ai
+OAUTH_CLIENT_ID=requestshield-cli
+OAUTH_RESOURCE=urn:theair:management-api:dev

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "requestshield",
-  "version": "2.1.0-stg.427",
+  "version": "2.2.0-qat.440",
   "description": "Customer CLI for IntelliFend RequestShield.",
   "type": "module",
   "bin": {
@@ -9,11 +9,11 @@
   "publishConfig": {
     "access": "public",
     "registry": "https://registry.npmjs.org/",
-    "tag": "stg"
+    "tag": "qat"
   },
   "files": [
     "src/",
-    "config/.env.stg",
+    "config/.env.qat",
     "skills/",
     "README.md"
   ],
@@ -22,6 +22,6 @@
   },
   "license": "UNLICENSED",
   "requestshield": {
-    "profile": "stg"
+    "profile": "qat"
   }
 }

package/skills/requestshield/SKILL.md

@@ -111,6 +111,8 @@ writing integration code: **Detect existing integration** →
 2. **Backend side** — follow the selected path's reference:
    [Spring Boot 3 starter](references/backend-spring-boot.md) or
    [Java core SDK](references/backend-java-core.md). Enforce before the mutation.
+   Java 2.1.0+ passes the request host to `verify` for the phishing check and
+   requires Browser SDK 2.x; Browser SDK 1.x tokens are blocked in `BLOCK` mode.
 3. **Static install verification** — run **Verifying**, then focused builds/tests
    without starting a credential-dependent runtime. Fix failures before finishing.
 

package/skills/requestshield/references/backend-java-core.md

@@ -79,7 +79,7 @@ all our users" — a startup failure is far cheaper to diagnose than that.
 
 ```java
 String token = request.getHeader("X-IntelliFend-Token");
-VerificationResult result = requestShield.verify(token);
+VerificationResult result = requestShield.verify(token, request.getServerName());
 
 if (!result.isAllowed()) {
     rejectRequest(result.getReason().getCode());
@@ -99,6 +99,13 @@ continueProtectedOperation();
   application code.** Reason codes explain a decision; they do not amend it, and an
   override that allows a blocked reason quietly removes the protection.
 
+  Pass the host the API was called on (`request.getServerName()` or the `Host`
+  header), never `Origin`. Java 2.1.0+ then blocks requests relayed through a
+  phishing proxy with reason `phishing`, without consuming the token. This needs
+  Browser SDK 2.x on the v2 API, a backend that sees the public host (configure
+  forwarded headers behind a proxy), and a page and API on the same root domain.
+  On Java 2.0.0, `verify(token, host)` does not exist; use `verify(token)`.
+
 Backend Manual names this explicit integration style. The core SDK has no starter
 `mode` property; documentation should describe the application's observed handling of
 `isAllowed()` rather than inventing a `BLOCK` or `MONITOR` configuration option.

package/skills/requestshield/references/backend-spring-boot.md

@@ -44,7 +44,7 @@ a handler covered by the annotation must not also call `verify()`.
 <dependency>
   <groupId>com.intellifend.requestshield</groupId>
   <artifactId>requestshield-spring-boot3-starter</artifactId>
-  <version>2.0.0</version>
+  <version>2.1.0</version>
 </dependency>
 ```
 
@@ -54,11 +54,11 @@ repositories {
 }
 
 dependencies {
-    implementation("com.intellifend.requestshield:requestshield-spring-boot3-starter:2.0.0")
+    implementation("com.intellifend.requestshield:requestshield-spring-boot3-starter:2.1.0")
 }
 ```
 
-The starter includes `requestshield-backend-sdk:2.0.0` — do not declare both.
+The starter includes `requestshield-backend-sdk:2.1.0` — do not declare both.
 
 ## 2. Configure
 
@@ -81,6 +81,13 @@ intellifend:
 Java SDK 2.0.0 uses API v2 for verification and availability checks; there is no
 API-version setting. Existing Java 1.0.0 integrations continue using v1.
 
+From 2.1.0 the starter also passes `request.getServerName()` to the phishing check:
+`BLOCK` rejects a `phishing` result, `MONITOR` lets it through. It requires Browser
+SDK 2.x on the v2 API (see `integration-planning.md`). Behind a reverse proxy or load
+balancer, set `server.forward-headers-strategy` so `getServerName()` is the public
+host; otherwise every request returns `phishing`. Page and API must share a root
+domain.
+
 Bind the secret with no fallback default, so an environment that fails to inject it
 fails at startup. A backend that starts with a placeholder secret rejects every real
 token, which surfaces days later as "RequestShield is blocking all our users" — a

package/skills/requestshield/references/integration-planning.md

@@ -130,9 +130,16 @@ their browser, CSP, or Java requirements.
 | Browser 2.0.0 | v2 by default; `apiVersion: 'v1' \| 'v2'` or `data-api-version` selects it. |
 | Java 1.0.0 | v1, without an API-version option. |
 | Java 2.0.0 core and Spring Boot starter | v2 only; no builder or Spring API-version option. |
+| Java 2.1.0+ core and Spring Boot starter | v2 only; requires Browser 2.x tokens (v2 API) for the phishing check. |
 
-For new integrations, prefer matching browser and backend API versions. Mixed
-versions can verify compatible tokens, and a token remains single-use across
+Java 2.1.0 and later require Browser SDK 2.x on the v2 API. Browser 1.0.0, or
+Browser 2.x with `apiVersion: 'v1'`, with Java 2.1.0+ is not a supported pair:
+its tokens fail the phishing check, so `verify(token, requestHost)` and the
+Spring starter return `phishing` and block in `BLOCK` mode. Upgrade the browser
+before or together with the backend. Do not pin Java 2.1.0+ behind a v1 browser.
+
+For new integrations, use matching browser and backend versions. With Java 2.0.0,
+mixed versions can verify compatible tokens, and a token remains single-use across
 both APIs. Backend availability checks observe only the API used by its SDK.
 If the browser's other API cannot issue a token while the backend's API is
 healthy, the backend can reject with `missing_token`. Check this behavior when

package/config/.env.stg

@@ -1,7 +0,0 @@
-# Public staging settings for the STG npm release and source runner. Never add secrets.
-API_URL=https://management-api-stg.intellifend.ai
-CHALLENGE_URL=https://challenge-stg.intellifend.ai
-DOCS_URL=https://docs-stg.intellifend.ai
-OAUTH_ISSUER=https://auth-stg.intellifend.ai
-OAUTH_CLIENT_ID=requestshield-cli
-OAUTH_RESOURCE=urn:theair:management-api:stg