Cwikius-Spring/spring-security
1
0
Fork 0
mirror of https://github.com/spring-projects/spring-security.git synced 2025-07-10 04:13:31 +00:00
Code Issues Packages Projects Releases Wiki Activity

Fix inline code formatting in documentation

Browse Source 
Signed-off-by: Hao <kyrieeeee2@gmail.com>
This commit is contained in:
Hao 2025-03-11 15:15:27 +08:00 committed by Josh Cummings
parent 8c7d2e8922
commit 6159e089d4
2 changed files with 5 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
docs/modules/ROOT/pages/servlet/oauth2/resource-server/multitenancy.adoc
View File

@ -320,7 +320,7 @@ class TenantJWSKeySelector(tenants: TenantRepository) : JWTClaimsSetAwareJWSKeyS
----
======
<1> A hypothetical source for tenant information
<2> A cache for `JWSKeySelector`s, keyed by tenant identifier
<2> A cache for ``JWSKeySelector``s, keyed by tenant identifier
<3> Looking up the tenant is more secure than simply calculating the JWK Set endpoint on the fly - the lookup acts as a list of allowed tenants
<4> Create a `JWSKeySelector` via the types of keys that come back from the JWK Set endpoint - the lazy lookup here means that you don't need to configure all tenants at startup

8
docs/modules/ROOT/pages/servlet/saml2/login/overview.adoc
View File

@ -639,7 +639,7 @@ class MyCustomSecurityConfiguration {
----
======
In this way, the set of `RelyingPartyRegistration`s will refresh based on {spring-framework-reference-url}integration/cache/store-configuration.html[the cache's eviction schedule].
In this way, the set of ``RelyingPartyRegistration``s will refresh based on {spring-framework-reference-url}integration/cache/store-configuration.html[the cache's eviction schedule].
[[servlet-saml2login-relyingpartyregistration]]
== RelyingPartyRegistration
@ -971,9 +971,9 @@ As seen so far, Spring Security resolves the `RelyingPartyRegistration` by looki
Depending on the use case, a number of other strategies are also employed to derive one.
For example:
* For processing `<saml2:Response>`s, the `RelyingPartyRegistration` is looked up from the associated `<saml2:AuthRequest>` or from the `<saml2:Response#Issuer>` element
* For processing `<saml2:LogoutRequest>`s, the `RelyingPartyRegistration` is looked up from the currently logged in user or from the `<saml2:LogoutRequest#Issuer>` element
* For publishing metadata, the `RelyingPartyRegistration`s are looked up from any repository that also implements `Iterable<RelyingPartyRegistration>`
* For processing ``<saml2:Response>``s, the `RelyingPartyRegistration` is looked up from the associated `<saml2:AuthRequest>` or from the `<saml2:Response#Issuer>` element
* For processing ``<saml2:LogoutRequest>``s, the `RelyingPartyRegistration` is looked up from the currently logged in user or from the `<saml2:LogoutRequest#Issuer>` element
* For publishing metadata, the ``RelyingPartyRegistration``s are looked up from any repository that also implements `Iterable<RelyingPartyRegistration>`
When this needs adjustment, you can turn to the specific components for each of these endpoints targeted at customizing this: