Fix Documentation Typos

This commit is contained in:
Tran Ngoc Nhan 2024-11-09 23:28:30 +07:00 committed by Josh Cummings
parent b168ec5f0d
commit 40f8ac642a
8 changed files with 8 additions and 8 deletions

View File

@ -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.

View File

@ -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.

View File

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

View File

@ -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**

View File

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

View File

@ -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]
----

View File

@ -797,7 +797,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:

View File

@ -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