This is an automated email from the ASF dual-hosted git repository.
janhoy pushed a commit to branch branch_10_0
in repository https://gitbox.apache.org/repos/asf/solr.git
The following commit(s) were added to refs/heads/branch_10_0 by this push:
new bae6371abce Fix Solr 10.0.0 JWT documentation.
bae6371abce is described below
commit bae6371abce1dacbc5204a3282cbc8695c33dbe6
Author: Jan Høydahl <[email protected]>
AuthorDate: Wed May 20 15:24:20 2026 +0200
Fix Solr 10.0.0 JWT documentation.
---
.../deployment-guide/pages/jwt-authentication-plugin.adoc | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git
a/solr/solr-ref-guide/modules/deployment-guide/pages/jwt-authentication-plugin.adoc
b/solr/solr-ref-guide/modules/deployment-guide/pages/jwt-authentication-plugin.adoc
index 9c8551033f1..f0af9692dd0 100644
---
a/solr/solr-ref-guide/modules/deployment-guide/pages/jwt-authentication-plugin.adoc
+++
b/solr/solr-ref-guide/modules/deployment-guide/pages/jwt-authentication-plugin.adoc
@@ -42,9 +42,14 @@ The simplest possible `security.json` for registering the
plugin without configu
}
----
-The plugin will by default require a valid JWT token for all traffic.
+[WARNING]
+====
+Earlier versions of this documentation incorrectly stated that `blockUnknown`
defaulted to `true`. The actual default is `false`, meaning requests without a
JWT token are passed through unauthenticated. If you intend to require
authentication for all requests, you must explicitly set `"blockUnknown": true`
in your `security.json`.
+====
+
+By default, `blockUnknown` is `false`, so requests without a JWT token are
passed through unauthenticated.
-If the `blockUnknown` property is set to `false` as in the above example, it
is possible to start configuring the plugin using unauthenticated REST API
calls, which is further described in section <<Editing JWT Authentication
Plugin Configuration>>.
+With `blockUnknown` set to `false` (the default, as shown above), you can
configure the plugin using unauthenticated REST API calls, which is further
described in section <<Editing JWT Authentication Plugin Configuration>>.
== Configuration Parameters
@@ -52,7 +57,7 @@ If the `blockUnknown` property is set to `false` as in the
above example, it is
[%header,format=csv,separator=;,cols="25%,50%,25%"]
|===
Key ; Description
; Default
-blockUnknown ; Set to `false` to if you need to perform configuration
through REST API or if you use an Authorization Plugin and only want certain
paths protected. By default all requests will require a token ; `true`
+blockUnknown ; Set to `true` to require a valid JWT token for all
requests. Set to `false` (the default) to allow unauthenticated requests
through — useful when configuring via REST API or when an Authorization Plugin
handles path-based protection ; `false`
realm ; Name of the authentication realm to echo back in HTTP
401 responses. Will also be displayed in Admin UI login page ; 'solr-jwt'
scope ; Whitespace separated list of valid scopes. If
configured, the JWT access token MUST contain a `scope` claim with at least one
of the listed scopes. Example: `solr:read solr:admin` ;
requireIss ; Fails requests that lacks an `iss` (issuer) claim
; `true`
@@ -167,7 +172,7 @@ Let's look at a more complex configuration, this time with
two issuers configure
Let's comment on this config:
<1> Plugin class
-<2> Make sure to block anyone without a valid token (this is also the default)
+<2> Explicitly block anyone without a valid token (the default is `false`, so
this must be set explicitly to enforce authentication)
<3> Fetch the user id from another claim than the default `sub`
<4> Require that the `foo` claim is one of "A" or "B" and that the `dept`
claim is "IT"
<5> Require one of the scopes `solr:read`, `solr:write` or `solr:admin`
