@intellifend/requestshieldjs 2.0.0-qat.204 → 2.0.0-qat.211
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +23 -1
- package/dist/checksums.json +5 -5
- package/dist/intellifend.js +2 -2
- package/dist/intellifend.mjs +2 -2
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -2,6 +2,24 @@
|
|
|
2
2
|
|
|
3
3
|
The RequestShield Browser SDK obtains single-use proof-of-work tokens and either attaches them automatically to configured Fetch and asynchronous XHR requests or returns them for application-controlled transport. The customer backend remains the authority that verifies a token and decides how to handle a missing token.
|
|
4
4
|
|
|
5
|
+
## Choose integration modes
|
|
6
|
+
|
|
7
|
+
Choose the frontend and backend modes independently:
|
|
8
|
+
|
|
9
|
+
| Side | Seamless | Manual |
|
|
10
|
+
| --- | --- | --- |
|
|
11
|
+
| Frontend (Browser SDK) | Configure `protect`; the SDK obtains and attaches a token to matching Fetch and asynchronous XHR requests. | Call `getToken()` and attach the returned token in application code. |
|
|
12
|
+
| Java backend | Use the Spring Boot 3 MVC starter and annotate the protected handler; the starter extracts the header, verifies the token and applies its enforcement policy. | Extract the token, call the Java core SDK's `verify(token)` and apply `VerificationResult` before the protected operation. |
|
|
13
|
+
|
|
14
|
+
For a new integration, prefer Seamless on both sides when the browser transport
|
|
15
|
+
is supported and the backend uses Spring Boot 3 MVC. Otherwise, prefer Manual
|
|
16
|
+
on both sides. All four combinations are supported, so an existing combination
|
|
17
|
+
or an explicit choice can be kept. Backend Seamless requires the token in
|
|
18
|
+
`X-IntelliFend-Token`, including when the frontend uses Manual mode.
|
|
19
|
+
|
|
20
|
+
`BLOCK` and `MONITOR` are Spring starter enforcement policies, separate from these
|
|
21
|
+
integration modes. Choosing frontend Seamless does not enable backend protection.
|
|
22
|
+
|
|
5
23
|
## Install
|
|
6
24
|
|
|
7
25
|
### npm / ESM
|
|
@@ -200,7 +218,11 @@ For a cross-origin protected application API, allow the `X-IntelliFend-Token` re
|
|
|
200
218
|
|
|
201
219
|
### Manual transport
|
|
202
220
|
|
|
203
|
-
`X-IntelliFend-Token` is the recommended
|
|
221
|
+
`X-IntelliFend-Token` is the recommended carrier for frontend Manual mode and is
|
|
222
|
+
required by backend Seamless. A dedicated request-body or form field is also
|
|
223
|
+
valid with backend Manual, where application code extracts it before verification.
|
|
224
|
+
Never place a token in a URL path, query string, or fragment because those
|
|
225
|
+
locations are commonly logged and cached.
|
|
204
226
|
|
|
205
227
|
### Challenge Server proxies
|
|
206
228
|
|
package/dist/checksums.json
CHANGED
|
@@ -1,18 +1,18 @@
|
|
|
1
1
|
{
|
|
2
|
-
"version": "2.0.0-qat.
|
|
2
|
+
"version": "2.0.0-qat.211",
|
|
3
3
|
"algorithm": "sha384",
|
|
4
4
|
"bundles": [
|
|
5
5
|
{
|
|
6
6
|
"name": "intellifend",
|
|
7
7
|
"path": "intellifend.js",
|
|
8
|
-
"version": "2.0.0-qat.
|
|
9
|
-
"integrity": "sha384-
|
|
8
|
+
"version": "2.0.0-qat.211",
|
|
9
|
+
"integrity": "sha384-uSFJiosGxa7BN8DIl3XvpILMhGXyWGuf1bSdW3zszbJc2dnURhUbhPWxMOGxTeHi"
|
|
10
10
|
},
|
|
11
11
|
{
|
|
12
12
|
"name": "intellifend-esm",
|
|
13
13
|
"path": "intellifend.mjs",
|
|
14
|
-
"version": "2.0.0-qat.
|
|
15
|
-
"integrity": "sha384-
|
|
14
|
+
"version": "2.0.0-qat.211",
|
|
15
|
+
"integrity": "sha384-dFwy9vbHXbjtmymion5tAnmawA+1kqXUMDLUsDqQjktg2fTpfS+Vj7WN7RLQ8QXA"
|
|
16
16
|
}
|
|
17
17
|
]
|
|
18
18
|
}
|