From cfe13c7c7673012f60f610ce9aa32ffc3400a72c Mon Sep 17 00:00:00 2001 From: Tran Ngoc Nhan Date: Tue, 13 Jan 2026 23:59:37 +0700 Subject: [PATCH] Fix typos Signed-off-by: Tran Ngoc Nhan --- .../reactive/oauth2/client/authorization-grants.adoc | 2 +- .../ROOT/pages/reactive/oauth2/client/core.adoc | 4 ++-- .../ROOT/pages/reactive/oauth2/login/advanced.adoc | 2 +- .../pages/reactive/oauth2/resource-server/jwt.adoc | 2 +- .../ROOT/pages/servlet/appendix/database-schema.adoc | 2 +- .../ROOT/pages/servlet/appendix/namespace/http.adoc | 2 +- .../servlet/authentication/kerberos/appendix.adoc | 10 +++++----- .../pages/servlet/authentication/kerberos/samples.adoc | 4 ++-- .../modules/ROOT/pages/servlet/configuration/java.adoc | 4 ++-- .../ROOT/pages/servlet/configuration/kotlin.adoc | 2 +- 10 files changed, 17 insertions(+), 17 deletions(-) diff --git a/docs/modules/ROOT/pages/reactive/oauth2/client/authorization-grants.adoc b/docs/modules/ROOT/pages/reactive/oauth2/client/authorization-grants.adoc index f40f3dee9d..8fb76bca2c 100644 --- a/docs/modules/ROOT/pages/reactive/oauth2/client/authorization-grants.adoc +++ b/docs/modules/ROOT/pages/reactive/oauth2/client/authorization-grants.adoc @@ -74,7 +74,7 @@ spring: ---- Public Clients are supported using https://tools.ietf.org/html/rfc7636[Proof Key for Code Exchange] (PKCE). -If the client is running in an untrusted environment (eg. native application or web browser-based application) and therefore incapable of maintaining the confidentiality of it's credentials, PKCE will automatically be used when the following conditions are true: +If the client is running in an untrusted environment (e.g. native application or web browser-based application) and therefore incapable of maintaining the confidentiality of its credentials, PKCE will automatically be used when the following conditions are true: . `client-secret` is omitted (or empty) . `client-authentication-method` is set to "none" (`ClientAuthenticationMethod.NONE`) diff --git a/docs/modules/ROOT/pages/reactive/oauth2/client/core.adoc b/docs/modules/ROOT/pages/reactive/oauth2/client/core.adoc index d95a8f35da..bbd16001d8 100644 --- a/docs/modules/ROOT/pages/reactive/oauth2/client/core.adoc +++ b/docs/modules/ROOT/pages/reactive/oauth2/client/core.adoc @@ -250,7 +250,7 @@ The primary responsibilities include: * Delegating to a `ReactiveOAuth2AuthorizationFailureHandler` when an OAuth 2.0 Client fails to authorize (or re-authorize). A `ReactiveOAuth2AuthorizedClientProvider` implements a strategy for authorizing (or re-authorizing) an OAuth 2.0 Client. -Implementations will typically implement an authorization grant type, eg. `authorization_code`, `client_credentials`, etc. +Implementations will typically implement an authorization grant type, e.g. `authorization_code`, `client_credentials`, etc. The default implementation of `ReactiveOAuth2AuthorizedClientManager` is `DefaultReactiveOAuth2AuthorizedClientManager`, which is associated with a `ReactiveOAuth2AuthorizedClientProvider` that may support multiple authorization grant types using a delegation-based composite. The `ReactiveOAuth2AuthorizedClientProviderBuilder` may be used to configure and build the delegation-based composite. @@ -306,7 +306,7 @@ fun authorizedClientManager( ====== When an authorization attempt succeeds, the `DefaultReactiveOAuth2AuthorizedClientManager` will delegate to the `ReactiveOAuth2AuthorizationSuccessHandler`, which (by default) will save the `OAuth2AuthorizedClient` via the `ServerOAuth2AuthorizedClientRepository`. -In the case of a re-authorization failure, eg. a refresh token is no longer valid, the previously saved `OAuth2AuthorizedClient` will be removed from the `ServerOAuth2AuthorizedClientRepository` via the `RemoveAuthorizedClientReactiveOAuth2AuthorizationFailureHandler`. +In the case of a re-authorization failure, e.g. a refresh token is no longer valid, the previously saved `OAuth2AuthorizedClient` will be removed from the `ServerOAuth2AuthorizedClientRepository` via the `RemoveAuthorizedClientReactiveOAuth2AuthorizationFailureHandler`. The default behaviour may be customized via `setAuthorizationSuccessHandler(ReactiveOAuth2AuthorizationSuccessHandler)` and `setAuthorizationFailureHandler(ReactiveOAuth2AuthorizationFailureHandler)`. The `DefaultReactiveOAuth2AuthorizedClientManager` is also associated with a `contextAttributesMapper` of type `Function>>`, which is responsible for mapping attribute(s) from the `OAuth2AuthorizeRequest` to a `Map` of attributes to be associated to the `OAuth2AuthorizationContext`. diff --git a/docs/modules/ROOT/pages/reactive/oauth2/login/advanced.adoc b/docs/modules/ROOT/pages/reactive/oauth2/login/advanced.adoc index 1386480e09..5ffb6bae84 100644 --- a/docs/modules/ROOT/pages/reactive/oauth2/login/advanced.adoc +++ b/docs/modules/ROOT/pages/reactive/oauth2/login/advanced.adoc @@ -675,7 +675,7 @@ The ID Token is represented as a https://tools.ietf.org/html/rfc7519[JSON Web To The `ReactiveOidcIdTokenDecoderFactory` provides a `ReactiveJwtDecoder` used for `OidcIdToken` signature verification. The default algorithm is `RS256` but may be different when assigned during client registration. For these cases, a resolver may be configured to return the expected JWS algorithm assigned for a specific client. -The JWS algorithm resolver is a `Function` that accepts a `ClientRegistration` and returns the expected `JwsAlgorithm` for the client, eg. `SignatureAlgorithm.RS256` or `MacAlgorithm.HS256` +The JWS algorithm resolver is a `Function` that accepts a `ClientRegistration` and returns the expected `JwsAlgorithm` for the client, e.g. `SignatureAlgorithm.RS256` or `MacAlgorithm.HS256` The following code shows how to configure the `OidcIdTokenDecoderFactory` `@Bean` to default to `MacAlgorithm.HS256` for all `ClientRegistration`: diff --git a/docs/modules/ROOT/pages/reactive/oauth2/resource-server/jwt.adoc b/docs/modules/ROOT/pages/reactive/oauth2/resource-server/jwt.adoc index 7858d29fbe..6e9a8a11b2 100644 --- a/docs/modules/ROOT/pages/reactive/oauth2/resource-server/jwt.adoc +++ b/docs/modules/ROOT/pages/reactive/oauth2/resource-server/jwt.adoc @@ -1017,7 +1017,7 @@ class AudienceValidator : OAuth2TokenValidator { ---- ====== -Then, to add into a resource server, you can specifying the `ReactiveJwtDecoder` instance: +Then, to add into a resource server, you can specify the `ReactiveJwtDecoder` instance: [tabs] ====== diff --git a/docs/modules/ROOT/pages/servlet/appendix/database-schema.adoc b/docs/modules/ROOT/pages/servlet/appendix/database-schema.adoc index 0a45d92161..39c205bb77 100644 --- a/docs/modules/ROOT/pages/servlet/appendix/database-schema.adoc +++ b/docs/modules/ROOT/pages/servlet/appendix/database-schema.adoc @@ -76,7 +76,7 @@ create table group_members ( ); ---- -Remember that these tables are required only if you us the provided JDBC `UserDetailsService` implementation. +Remember that these tables are required only if you use the provided JDBC `UserDetailsService` implementation. If you write your own or choose to implement `AuthenticationProvider` without a `UserDetailsService`, you have complete freedom over how you store the data, as long as the interface contract is satisfied. diff --git a/docs/modules/ROOT/pages/servlet/appendix/namespace/http.adoc b/docs/modules/ROOT/pages/servlet/appendix/namespace/http.adoc index 59a0cbcd51..6e4fc1bbd4 100644 --- a/docs/modules/ROOT/pages/servlet/appendix/namespace/http.adoc +++ b/docs/modules/ROOT/pages/servlet/appendix/namespace/http.adoc @@ -248,7 +248,7 @@ Optional attribute that specifies the bean name of a `CorsConfigurationSource` t [[nsa-headers]] == -This element allows for configuring additional (security) headers to be send with the response. +This element allows for configuring additional (security) headers to be sent with the response. It enables easy configuration for several headers and also allows for setting custom headers through the <> element. Additional information, can be found in the xref:features/exploits/headers.adoc#headers[Security Headers] section of the reference. diff --git a/docs/modules/ROOT/pages/servlet/authentication/kerberos/appendix.adoc b/docs/modules/ROOT/pages/servlet/authentication/kerberos/appendix.adoc index d71ebb988d..553ee19643 100644 --- a/docs/modules/ROOT/pages/servlet/authentication/kerberos/appendix.adoc +++ b/docs/modules/ROOT/pages/servlet/authentication/kerberos/appendix.adoc @@ -52,13 +52,13 @@ data with its own key. When `KDC` receives this authentication package from a client it checks who this `client` claims to be from an unencrypted part and based on that information it uses `client` decryption key it already have in -its database. If this decryption is succesfull `KDC` knows that this +its database. If this decryption is successful `KDC` knows that this `client` is the one it claims to be. What KDC returns to a client is a ticket called `Ticket Granting Ticket` which is signed by a KDC's own private key. Later when `client` sends back this ticket it can try to decrypt it and if that -operation is succesfull it knows that it was a ticket it itself +operation is successful it knows that it was a ticket it itself originally signed and gave to a `client`. image::{figures}/drawio-kerb-cc3.png[] @@ -75,7 +75,7 @@ When `client` is authenticating with a service it sends previously received service ticket to a service which then thinks that I don't know anything about this guy but he gave me an authentication ticket. What `service` can do next is try to decrypt that ticket and if that -operation is succesfull it knows that only other party who knows my +operation is successful it knows that only other party who knows my credentials is the `KDC` and because I trust him I can also trust that this client is a one he claims to be. @@ -394,7 +394,7 @@ Valid starting Expires Service principal Above you can see what happened if query was successful by looking kerberos tickets. Now you can experiment with further query commands -i.e. if you working with `KerberosLdapContextSource`. +i.e. if you are working with `KerberosLdapContextSource`. [source,text] ---- @@ -435,7 +435,7 @@ order to white list servers with Chrome will negotiate. Internet Explorer so if all changes were applied to IE (as described in E.3), nothing has to be passed via command-line parameters. - on Linux/Mac OS machines (clients): the command-line parameter - `--auth-negotiate-delegate-whitelist` should only used if Kerberos + `--auth-negotiate-delegate-whitelist` should only be used if Kerberos delegation is required (otherwise do not set this parameter). - It is recommended to use `https` for all communication. diff --git a/docs/modules/ROOT/pages/servlet/authentication/kerberos/samples.adoc b/docs/modules/ROOT/pages/servlet/authentication/kerberos/samples.adoc index db9a7eb89d..3b7a49a27f 100644 --- a/docs/modules/ROOT/pages/servlet/authentication/kerberos/samples.adoc +++ b/docs/modules/ROOT/pages/servlet/authentication/kerberos/samples.adoc @@ -189,7 +189,7 @@ In above we simply set `app.user-principal` and `app.keytab-location` to empty values which disables a use of keytab file. ==== -If operation is succesfull you should see below output with `user1@EXAMPLE.ORG`. +If operation is successful you should see below output with `user1@EXAMPLE.ORG`. [source,text] ---- ` that is a single argument to a public method on javadoc:org.springframework.security.config.annotation.web.builders.HttpSecurity[]. A few examples can help to clarify. -If `Customizer` is published as a Bean, it will not be be automatically applied because it is an argument to javadoc:org.springframework.security.config.annotation.web.configurers.HeadersConfigurer#contentTypeOptions(org.springframework.security.config.Customizer)[] which is not a method defined on `HttpSecurity`. +If `Customizer` is published as a Bean, it will not be automatically applied because it is an argument to javadoc:org.springframework.security.config.annotation.web.configurers.HeadersConfigurer#contentTypeOptions(org.springframework.security.config.Customizer)[] which is not a method defined on `HttpSecurity`. However, if `Customizer>` is published as a Bean, it will be automatically applied because it is an argument to javadoc:org.springframework.security.config.annotation.web.builders.HttpSecurity#headers(org.springframework.security.config.Customizer)[]. For example, the following configuration will ensure that the xref:servlet/exploits/headers.adoc#servlet-headers-csp[Content Security Policy] is set to `object-src 'none'`: @@ -710,7 +710,7 @@ include-code::./TopLevelCustomizerBeanConfiguration[tag=headersCustomizer,indent First each xref:#httpsecurity-customizer-bean[Customizer Bean] is applied using https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/beans/factory/ObjectProvider.html#orderedStream()[ObjectProvider#orderedStream()]. This means that if there are multiple `Customizer` Beans, the https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/core/annotation/Order.html[@Order] annotation can be added to the Bean definitions to control the ordering. -Next every xref:#top-level-customizer-bean[Top Level HttpSecurity Customizer Beans] type is looked up and each is is applied using `ObjectProvider#orderedStream()`. +Next every xref:#top-level-customizer-bean[Top Level HttpSecurity Customizer Beans] type is looked up and each is applied using `ObjectProvider#orderedStream()`. If there is are two `Customizer>` beans and two `Customizer>` instances, the order that each `Customizer` type is invoked is undefined. However, the order that each instance of `Customizer>` is defined by `ObjectProvider#orderedStream()` and can be controlled using `@Order` on the Bean the definitions. diff --git a/docs/modules/ROOT/pages/servlet/configuration/kotlin.adoc b/docs/modules/ROOT/pages/servlet/configuration/kotlin.adoc index 964dde0e09..4c038fd0ba 100644 --- a/docs/modules/ROOT/pages/servlet/configuration/kotlin.adoc +++ b/docs/modules/ROOT/pages/servlet/configuration/kotlin.adoc @@ -399,7 +399,7 @@ Second, each xref:#httpsecuritydsl-bean[HttpSecurityDsl.() -> Unit Beans] is app This means that if there are multiple `HttpSecurity.() -> Unit` Beans, the https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/core/annotation/Order.html[@Order] annotation can be added to the Bean definitions to control the ordering. Next, every xref:#top-level-dsl-bean[Top Level Security Dsl Beans] type is looked up and each is is applied using `ObjectProvider#orderedStream()`. -If there is are different types of top level security Beans (.e.g. `HeadersDsl.() -> Unit` and `HttpsRedirectDsl.() -> Unit`), then the order that each Dsl type is invoked is undefined. +If there is are different types of top level security Beans (e.g. `HeadersDsl.() -> Unit` and `HttpsRedirectDsl.() -> Unit`), then the order that each Dsl type is invoked is undefined. However, the order that each instance of of the same top level security Bean type is defined by `ObjectProvider#orderedStream()` and can be controlled using `@Order` on the Bean the definitions. Finally, the `HttpSecurityDsl` Bean is injected as a Bean.