Fix Documentation Typos

Author: ngocnhan-tran1996

docs/modules/ROOT/pages/features/integrations/localization.adoc

@@ -5,7 +5,7 @@ If your application is designed for English-speaking users, you don't need to do
 If you need to support other locales, everything you need to know is contained in this section.
 
 All exception messages can be localized, including messages related to authentication failures and access being denied (authorization failures).
-Exceptions and logging messages that are focused on developers or system deplopers (including incorrect attributes, interface contract violations, using incorrect constructors, startup time validation, debug-level logging) are not localized and instead are hard-coded in English within Spring Security's code.
+Exceptions and logging messages that are focused on developers or system deployers (including incorrect attributes, interface contract violations, using incorrect constructors, startup time validation, debug-level logging) are not localized and instead are hard-coded in English within Spring Security's code.
 
 Shipping in the `spring-security-core-xx.jar` you will find an `org.springframework.security` package that in turn contains a `messages.properties` file, as well as localized versions for some common languages.
 This should be referred to by your `ApplicationContext`, as Spring Security classes implement Spring's `MessageSourceAware` interface and expect the message resolver to be dependency injected at application context startup time.

docs/modules/ROOT/pages/reactive/getting-started.adoc

@@ -75,7 +75,7 @@ Using generated security password: 8e557245-73e2-4286-969a-ff57fe326336
 [[authenticating]]
 == Authenticating
 
-You can access the application at http://localhost:8080/ which will redirect the browser to the default log in page. You can provide the default username of `user` with the randomly generated password that is logged to the console. The browser is then taken to the orginally requested page.
+You can access the application at http://localhost:8080/ which will redirect the browser to the default log in page. You can provide the default username of `user` with the randomly generated password that is logged to the console. The browser is then taken to the originally requested page.
 
 To log out you can visit http://localhost:8080/logout and then confirming you wish to log out.
 

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

@@ -96,7 +96,7 @@ this.rest.get()
 ----
 ======
 
-The prececing example invokes the `https://other-service.example.com/endpoint`, adding the bearer token `Authorization` header for you.
+The preceding example invokes the `https://other-service.example.com/endpoint`, adding the bearer token `Authorization` header for you.
 
 In places where you need to override this behavior, you can supply the header yourself:
 

docs/modules/ROOT/pages/servlet/appendix/namespace/method-security.adoc

@@ -287,7 +287,7 @@ Use AuthorizationManager API instead of AccessDecisionManager (defaults to true)
 
 [[nsa-intercept-methods-authorization-manager-ref]]
 * **authorization-manager-ref**
-Optional AuthorizationManager bean ID to be used instead of the default (supercedes use-authorization-manager)
+Optional AuthorizationManager bean ID to be used instead of the default (supersedes use-authorization-manager)
 
 [[nsa-intercept-methods-access-decision-manager-ref]]
 * **access-decision-manager-ref**

docs/modules/ROOT/pages/servlet/authentication/rememberme.adoc

@@ -50,7 +50,7 @@ If you have more than one in your application context, you need to specify which
 
 [[remember-me-persistent-token]]
 == Persistent Token Approach
-This approach is based on the article https://web.archive.org/web/20180819014446/http://jaspan.com/improved_persistent_login_cookie_best_practice[Improved Persistent Login Cookie Best Practice] with some minor modifications  footnote:[Essentially, the username is not included in the cookie, to prevent exposing a valid login name unecessarily.
+This approach is based on the article https://web.archive.org/web/20180819014446/http://jaspan.com/improved_persistent_login_cookie_best_practice[Improved Persistent Login Cookie Best Practice] with some minor modifications  footnote:[Essentially, the username is not included in the cookie, to prevent exposing a valid login name unnecessarily.
 There is a discussion on this in the comments section of this article.].
 To use this approach with namespace configuration, you would supply a datasource reference:
 

docs/modules/ROOT/pages/servlet/authentication/runas.adoc

@@ -12,7 +12,7 @@ Because Spring Security provides a number of helper classes that automatically c
 
 [[runas-config]]
 == Configuration
-Spring Security provices a `RunAsManager` interface:
+Spring Security provides a `RunAsManager` interface:
 
 [source,java]
 ----

docs/modules/ROOT/pages/servlet/authorization/method-security.adoc

@@ -796,7 +796,7 @@ In-memory filtering can obviously be expensive, and so be considerate of whether
 === Authorizing Method Invocation with `@Secured`
 
 javadoc:org.springframework.security.access.annotation.Secured[format=annotation] is a legacy option for authorizing invocations.
-<<use-preauthorize,`@PreAuthorize`>> supercedes it and is recommended instead.
+<<use-preauthorize,`@PreAuthorize`>> supersedes it and is recommended instead.
 
 To use the `@Secured` annotation, you should first change your Method Security declaration to enable it like so:
 

docs/modules/ROOT/pages/servlet/saml2/metadata.adoc

@@ -120,7 +120,7 @@ class RefreshableRelyingPartyRegistrationRepository : IterableRelyingPartyRegist
 ======
 
 [TIP]
-`OpenSaml4AssertingPartyMetadataRepository` also ships with a constructor so you can provide a custom `MetadataResolver`. Since the underlying `MetadataResolver` is doing the expirying and refreshing, if you use the constructor directly, you will only get these features by providing an implementation that does so.
+`OpenSaml4AssertingPartyMetadataRepository` also ships with a constructor so you can provide a custom `MetadataResolver`. Since the underlying `MetadataResolver` is doing the expiring and refreshing, if you use the constructor directly, you will only get these features by providing an implementation that does so.
 
 === Verifying Metadata Signatures