Fix typos

Signed-off-by: Tran Ngoc Nhan <ngocnhan.tran1996@gmail.com>

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`)

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<OAuth2AuthorizeRequest, Mono<Map<String, Object>>>`, which is responsible for mapping attribute(s) from the `OAuth2AuthorizeRequest` to a `Map` of attributes to be associated to the `OAuth2AuthorizationContext`.

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`:
 

docs/modules/ROOT/pages/reactive/oauth2/resource-server/jwt.adoc

@@ -1017,7 +1017,7 @@ class AudienceValidator : OAuth2TokenValidator<Jwt> {
 ----
 ======
 
-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]
 ======

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.
 
 

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]]
 == <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 <<nsa-header,header>> element.
 Additional information, can be found in the xref:features/exploits/headers.adoc#headers[Security Headers] section of the reference.
 

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.
 

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]
 ----
 <html xmlns="https://www.w3.org/1999/xhtml"
@@ -209,7 +209,7 @@ Or use a `user2` with a keytab file.
 $ java -jar sec-client-rest-template-{spring-security-version}.jar
 ----
 
-If operation is succesfull you should see below output with `user2@EXAMPLE.ORG`.
+If operation is succesful you should see below output with `user2@EXAMPLE.ORG`.
 [source,text]
 ----
 <html xmlns="https://www.w3.org/1999/xhtml"

docs/modules/ROOT/pages/servlet/configuration/java.adoc

@@ -697,7 +697,7 @@ A top level `HttpSecurity` `Customizer` type can be summarized as any `Customize
 This translates to any `Customizer<T>` 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<ContentTypeOptionsConfig>` 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<ContentTypeOptionsConfig>` 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<HeadersConfigurer<HttpSecurity>>` 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<HttpSecurity> 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<HttpSecurity>` 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<HeadersConfigurer<HttpSecurity>>` beans and two `Customizer<HttpsRedirectConfigurer<HttpSecurity>>` instances, the order that each `Customizer` type is invoked is undefined.
 However, the order that each instance of `Customizer<HttpsRedirectConfigurer<HttpSecurity>>` is defined by `ObjectProvider#orderedStream()` and can be controlled using `@Order` on the Bean the definitions.
 

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.