Capitalize section headers across documentation files

Standardized capitalization for section headers to improve consistency across documentation. This includes changes like converting "## On Windows using IIS hosting" to "## On Windows Using IIS Hosting" and similar adjustments for all other headers.

Author: khalidabuhakmeh

README.md

@@ -1,7 +1,7 @@
 # docs.duendesoftware.com
 
 ---
-## Private branch notice
+## Private Branch Notice
 
 This respository is a private clone of Duende docs.duendesoftware.com repository (it is not a GitHub fork).
 
@@ -61,7 +61,7 @@ There are two ways to restructure content:
 * Internal (move content around in the current structure)
 * External (move content outside the current structure)
 
-### Internal restructuring
+### Internal Restructuring
 
 When doing internal restructuring, move the page to its new location and then update its frontmatter
 to include the old location:
@@ -78,7 +78,7 @@ Page content goes here
 
 This will generate the page at the new location, and put a redirect to it at the old location.
 
-### External restructuring
+### External Restructuring
 
 When moving a page outside the structure, or you need a redirect to another location altogether,
 edit the `astro.config.mjs` file and append a key/vaklue pair to the `redirects` property:

src/content/docs/accesstokenmanagement/advanced/DPoP.md

@@ -51,12 +51,12 @@ services.AddClientCredentialsTokenManagement()
    });
 ```
 
-## Proof Tokens at the token server's token endpoint
+## Proof Tokens At The Token Server's Token Endpoint
 
 Once the key has been configured for the client, then the library will use it to produce a DPoP proof token when calling the token server (including token renewals if relevant).
 There is nothing explicit needed on behalf of the developer using this library.
 
-### dpop_jkt at the token server's authorize endpoint
+### `dpop_jkt` At The token Server's Authorize Endpoint
 
 When using DPoP and `AddOpenIdConnectAccessTokenManagement`, this library will also automatically include the `dpop_jkt` parameter to the authorize endpoint.
 

src/content/docs/accesstokenmanagement/advanced/user-tokens.md

@@ -31,7 +31,7 @@ builder.Services.AddOpenIdConnectAccessTokenManagement(options =>
 });
 ```
 
-## Per request parameters
+## Per Request Parameters
 
 You can also modify token management parameters on a per-request basis. 
 

src/content/docs/accesstokenmanagement/blazor-server.md

@@ -61,7 +61,7 @@ public class OidcEvents : OpenIdConnectEvents
 
 Once registered and initialized, Duende.AccessTokenManagement will keep the store up to date automatically as tokens are refreshed.
 
-## Retrieving and using tokens
+## Retrieving And Using Tokens
 
 If you've registered your token store with `AddBlazorServerAccessTokenManagement`, Duende.AccessTokenManagement will register the services necessary to attach tokens to outgoing HTTP requests automatically, using the same API as a non-blazor application. You inject an HTTP client factory and resolve named HTTP clients where ever you need to make HTTP requests, and you register the HTTP client's that use access tokens in the DI system with our extension method:
 

src/content/docs/accesstokenmanagement/web-apps.md

@@ -76,7 +76,7 @@ builder.Services.AddOpenIdConnectAccessTokenManagement();
 
 ```
 
-### HTTP client factory
+### HTTP Client Factory
 
 Similar to the worker service support, you can register HTTP clients that automatically send the access token of the current user when making API calls. The message handler plumbing associated with those HTTP clients will try to make sure, the access token is always valid and not expired.
 
@@ -152,7 +152,7 @@ public class HomeController : Controller
 }
 ```
 
-### HTTP context extension methods
+### HTTP Context Extension Methods
 
 There are three extension methods on the HTTP context that simplify interaction with the token management service:
 
@@ -173,7 +173,7 @@ public async Task<IActionResult> CallApi()
 }
 ```
 
-### HTTP client factory
+### HTTP Client Factory
 
 Last but not least, if you registered clients with the factory, you can simply use them. They will try to make sure that a current access token is always sent along. If that is not possible, ultimately a 401 will be returned to the calling code.
 

src/content/docs/bff/architecture/third-party-cookies.md

@@ -25,7 +25,7 @@ OIDC Silent Login allows a client application to start its session without needi
 
 Similarly to OIDC Session Management, OIDC Silent Login relies on a hidden iframe, though in this case, the hidden iframe makes requests to the OP, passing the *prompt=none* parameter to indicate that user interaction isn't sensible. If that request includes the OP's session cookie, the OP can respond successfully and the application can obtain tokens. But if the request does not include a session - either because no session has been started or because the cookie has been blocked - then the silent login will fail, and the user will have to be redirected to the OP for an interactive login.
 
-### BFF with a Federation Gateway
+### BFF With A Federation Gateway
 
 The BFF supports silent login from the SPA with the /bff/silent-login [endpoint](/bff/fundamentals/session/management/silent-login). This endpoint is intended to be invoked in an iframe and issues a challenge to login non-interactively with *prompt=none*. Just as in a traditional SPA, this technique will be disrupted by third party cookie blocking when the BFF and OP are third parties.
 

src/content/docs/bff/architecture/ui-hosting.md

@@ -50,7 +50,7 @@ Microsoft's templates are easy-to-use at dev time from Visual Studio. They allow
 template proxies requests to the front end for you. At deploy time, that proxy is removed and the static assets of the
 site are served by the static file middleware.
 
-### Host the UI separately
+### Host The UI Separately
 
 You may want to host the UI outside the BFF. At development time, UI developers might prefer to run the frontend
 outside of Visual Studio (e.g., using the node cli). You might also want to have separate deployments of the frontend
@@ -82,7 +82,7 @@ In order for this architecture to work, the following things are needed:
 
 A sample of this approach is [available](/bff/samples#separate-host-for-ui).
 
-### Serve the index page from the BFF host
+### Serve The Index Page From The BFF Host
 
 Lastly, you could serve the index page of the SPA from the BFF, but have all the other static assets hosted on
 another host (presumably a CDN). This technique makes the UI and BFF have exactly the same origin, so the authentication

src/content/docs/bff/extensibility/http-forwarder.md

@@ -66,7 +66,7 @@ public class MyInvokerFactory : DefaultHttpMessageInvokerFactory
 services.AddSingleton<IHttpMessageInvokerFactory, MyInvokerFactory>();
 ```
 
-### Custom transformations
+### Custom Transformations
 In the standard configuration, BFF uses the YARP default behavior for forwarding HTTP requests. In addition, we
 
 * remove the sensitive session cookie

src/content/docs/bff/extensibility/tokens.md

@@ -34,7 +34,7 @@ builder.Services.AddHttpClient(
 You can also supply client assertions to the token management library. See this [sample](/bff/samples) for JWT-based client authentication.
 :::
 
-### Custom token storage
+### Custom Token Storage
 We recommend that you use the default storage mechanism, as this will automatically be compatible with the Duende.BFF server-side sessions.
 
 If you do not use server-side sessions, then the access and refresh token will be stored in the protected session cookie. If you want to change this, you can take over token storage completely.
@@ -83,7 +83,7 @@ public interface IUserTokenStore
 }
 ```
 
-### Per-route customized token retrieval
+### Per-route Customized Token Retrieval
 The token store defines how tokens are retrieved globally. However, you can add custom logic that changes the way that access tokens are retrieved on a per-route basis. For example, you might need to exchange a token to perform delegation or impersonation for some API calls, depending on the remote API. The interface that describes this extension point is the *IAccessTokenRetriever*.
 
 

src/content/docs/bff/fundamentals/apis/local.md

@@ -19,7 +19,7 @@ There are two styles of local APIs:
 #### Self-Contained Local APIs
 These APIs reside within the BFF and don't make HTTP requests to other APIs. They access data controlled by the BFF itself, which can simplify the architecture of the system by reducing the number of APIs that must be deployed and managed. They are suitable for scenarios where the BFF is the sole consumer of the data. If you require data accessibility from other applications or services, this approach is probably not suitable.
 
-#### Local APIs that Make Requests using Managed Access Tokens
+#### Local APIs That Make Requests Using Managed Access Tokens
 Alternatively, you can make the data available as a service and make HTTP requests to that service from your BFF's local endpoints. The benefits of this style of Local Endpoint include
 - Your frontend's network access can be simplified into an aggregated call for the specific data that it needs, which reduces the amount of data that must be sent to the client.
 - Your BFF endpoint can expose a subset of your remote APIs so that they are called in a more controlled manner than if the BFF proxied all requests to the endpoint. 
@@ -62,14 +62,14 @@ The example above is simplified to demonstrate the way that you might obtain a t
 ## Securing Local API Endpoints
 Regardless of the style of data access used by a local API, it must be protected against threats such as [CSRF (Cross-Site Request Forgery)](https://developer.mozilla.org/en-US/docs/Glossary/CSRF) attacks. To defend against such attacks and ensure that only the frontend can access these endpoints, we recommend implementing two layers of protection. 
 
-#### SameSite cookies
+#### SameSite Cookies
 
 [The SameSite cookie attribute](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie#samesitesamesite-value) is a feature of modern browsers that restricts cookies so that they are only sent to pages originating from the [site](https://developer.mozilla.org/en-US/docs/Glossary/Site) where the cookie was originally issued.
 
 This is a good first layer of defense, but makes the assumption that you can trust all subdomains of your site. All subdomains within a registrable domain are considered the same site for purposes of SameSite cookies. Thus, if another application hosted on a subdomain within your site is infected with malware, it can make CSRF attacks against your application.
 
 
-#### Anti-forgery header
+#### Anti-forgery Header
 
 For this reason, we recommend requiring an additional custom header on API endpoints, for example: