Fix internal broken links

Author: maartenba

.github/workflows/link-checker.yml

@@ -37,5 +37,5 @@ jobs:
         env:
           GITHUB_TOKEN: ${{secrets.GITHUB_TOKEN}}
         with:
-          args: "--no-progress --max-concurrency 8 --skip-missing --accept 200,429 --exclude-path root/llms.txt --exclude-path root/llms-full.txt --exclude-path root/llms-small.txt --exclude-loopback --require-https --exclude sample.duendesoftware.com --exclude docs.duendesoftware.com --exclude sitemap --exclude \"https://github.com/DuendeArchive/IdentityModel.AspNetCore/\" --root-dir \"$PWD/root\" root/**"
+          args: "--no-progress --max-concurrency 8 --skip-missing --accept 200,429 --exclude-path root/_llms-txt --exclude-path root/llms.txt --exclude-path root/llms-full.txt --exclude-path root/llms-small.txt --exclude-loopback --require-https --exclude sample.duendesoftware.com --exclude docs.duendesoftware.com --exclude sitemap --exclude \"https://github.com/DuendeArchive/IdentityModel.AspNetCore/\" --root-dir \"$PWD/root\" root/**"
           fail: true

package.json

@@ -20,8 +20,7 @@
     "build": "astro build",
     "preview": "astro preview",
     "astro": "astro",
-    "validateredirects": "cd _to-migrate/urls && node test-urls.js",
-    "linkchecker": " npm run build && lychee --skip-missing --no-progress --max-concurrency 16 --exclude-loopback --require-https --exclude sample.duendesoftware.com --exclude docs.duendesoftware.com --exclude sitemap --exclude github --root-dir \"$PWD/dist\" dist/**",
+    "linkchecker": "npm run build && lychee --skip-missing --no-progress --max-concurrency 16 --exclude-loopback --require-https --exclude-path dist/_llms-txt --exclude-path dist/llms.txt --exclude-path dist/llms-full.txt --exclude-path dist/llms-small.txt --exclude sample.duendesoftware.com --exclude docs.duendesoftware.com --exclude sitemap --exclude github --root-dir \"$PWD/dist\" dist/**",
     "postinstall": "patch-package"
   },
   "dependencies": {

src/content/docs/accesstokenmanagement/advanced/client-credentials.mdx

@@ -10,7 +10,7 @@ redirect_from:
 import { Code } from "@astrojs/starlight/components";
 import { Tabs, TabItem } from "@astrojs/starlight/components";
 
-The most common way to use the access token management for [machine-to-machine communication](/accesstokenmanagement/workers).
+The most common way to use the access token management for [machine-to-machine communication](/accesstokenmanagement/workers.mdx).
 However, you may want to customize certain aspects of it.
 
 ## Client Options

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

@@ -9,7 +9,7 @@ redirect_from:
 ---
 
 The most common way
-to use [access token management is for interactive web applications](/accesstokenmanagement/web-apps.md) -
+to use [access token management is for interactive web applications](/accesstokenmanagement/web-apps.mdx) -
 however, you may want to customize certain aspects of it. Here's what you can do.
 
 ## General Options

src/content/docs/accesstokenmanagement/index.mdx

@@ -18,7 +18,7 @@ The `Duende.AccessTokenManagement` library provides automatic access token manag
 
 :::note[Duende.AccessTokenManagement version 4 preview]
 Duende.AccessTokenManagement version 4 (preview) brings significant improvements, but also several breaking
-changes. Please see the [migration guide](/accesstokenmanagement/upgrading/atm-v3-to-v4/) and [release notes](https://github.com/DuendeSoftware/foss/releases/tag/atm-4.0.0-Preview.2).
+changes. Please see the [migration guide](/accesstokenmanagement/upgrading/atm-v3-to-v4.md) and [release notes](https://github.com/DuendeSoftware/foss/releases/tag/atm-4.0.0-Preview.2).
 :::
 
 ## Machine-To-Machine Token Management
@@ -29,7 +29,7 @@ To get started, install the NuGet Package:
 dotnet add package Duende.AccessTokenManagement
 ```
 
-See [Service Workers and Background Tasks](/accesstokenmanagement/workers.md) for more information on how to get started.
+See [Service Workers and Background Tasks](/accesstokenmanagement/workers.mdx) for more information on how to get started.
 
 <CardGrid>
     <LinkCard
@@ -52,7 +52,7 @@ To get started, install the NuGet Package:
 dotnet add package Duende.AccessTokenManagement.OpenIdConnect
 ```
 
-See [Web Applications](/accesstokenmanagement/web-apps.md) for more information on how to get started.
+See [Web Applications](/accesstokenmanagement/web-apps.mdx) for more information on how to get started.
 
 <CardGrid>
     <LinkCard

src/content/docs/accesstokenmanagement/workers.mdx

@@ -14,10 +14,10 @@ import { Tabs, TabItem } from "@astrojs/starlight/components";
 
 A common scenario in worker applications or background tasks (or really any daemon-style applications) is to call APIs using an OAuth token obtained via the client credentials flow.
 
-The access tokens need to be requested and [cached](/accesstokenmanagement/advanced/client-credentials/#token-caching) (either locally or shared between multiple instances) and made available to the code calling the APIs. In case of expiration (or other token invalidation reasons), a new access token needs to be requested.
+The access tokens need to be requested and [cached](/accesstokenmanagement/advanced/client-credentials.mdx#token-caching) (either locally or shared between multiple instances) and made available to the code calling the APIs. In case of expiration (or other token invalidation reasons), a new access token needs to be requested.
 The actual business code should not need to be aware of this.
 
-For more information, see the [advanced topic on client credentials](/accesstokenmanagement/advanced/client-credentials/).
+For more information, see the [advanced topic on client credentials](/accesstokenmanagement/advanced/client-credentials.mdx).
 
 :::note[Sample code]
 Take a look at the [`Worker` project in the samples folder](https://github.com/DuendeSoftware/foss/tree/main/access-token-management/samples/) for example code.

src/content/docs/bff/architecture/index.md

@@ -54,8 +54,8 @@ Duende.BFF uses ASP.NET's Cookie handler for session management. The cookie hand
 the application persisted in a digitally signed and encrypted cookie that is protected with modern cookie security
 features, including the Secure, HttpOnly and SameSite attributes. The handler also provides absolute and sliding session
 support, and has a flexible extensibility model, which Duende.BFF uses to
-implement [server-side session management](/bff/fundamentals/session/server-side-sessions/)
-and [back-channel logout support](/bff/fundamentals/session/management/back-channel-logout/).
+implement [server-side session management](/bff/fundamentals/session/server-side-sessions.mdx)
+and [back-channel logout support](/bff/fundamentals/session/management/back-channel-logout.md).
 
 ### Duende.AccessTokenManagement
 
@@ -67,27 +67,27 @@ actions can also be programmatically invoked through an imperative API.
 ### API Endpoints
 
 In the BFF architecture, the frontend makes API calls to backend services via the BFF host exclusively. Typically, the
-BFF acts as a reverse proxy to [remote APIs](/bff/fundamentals/apis/remote), providing session and token management.
-Implementing local APIs within the BFF host is also [possible](/bff/fundamentals/apis/local). Regardless, requests to
+BFF acts as a reverse proxy to [remote APIs](/bff/fundamentals/apis/remote.mdx), providing session and token management.
+Implementing local APIs within the BFF host is also [possible](/bff/fundamentals/apis/local.mdx). Regardless, requests to
 APIs are authenticated with the session cookie and need to be secured with an anti-forgery protection header.
 
 ### YARP
 
 Duende.BFF proxies requests to remote APIs using Microsoft's YARP (Yet Another Reverse Proxy). You can set up YARP using
 a simplified developer-centric configuration API provided by Duende.BFF, or if you have more complex requirements, you
 can use the full YARP configuration system directly. If you are using YARP directly, Duende.BFF
-provides [YARP integration](/bff/fundamentals/apis/yarp) to add BFF security and identity features.
+provides [YARP integration](/bff/fundamentals/apis/yarp.md) to add BFF security and identity features.
 
 ### UI Assets
 
 The BFF host typically serves at least some of the UI assets of the frontend, which can be HTML/JS/CSS, WASM, and/or
 server-rendered content. Serving the UI assets, or at least the index page of the UI from the same origin as the backend
 simplifies requests from the frontend to the backend. Doing so makes the two components same-origin, so that browsers
 will allow requests with no need to use CORS and automatically include cookies (including the crucial authentication
-cookie). This also avoids issues where [third-party cookie blocking](/bff/architecture/third-party-cookies) or the
+cookie). This also avoids issues where [third-party cookie blocking](/bff/architecture/third-party-cookies.md) or the
 SameSite cookie attribute prevents the frontend from sending the authentication cookie to the backend.
 
-It is also possible to separate the BFF and UI and host them separately. See [here](/bff/architecture/ui-hosting) for
+It is also possible to separate the BFF and UI and host them separately. See [here](/bff/architecture/ui-hosting.md) for
 more discussion of UI hosting architecture.
 
 ### Blazor Support

src/content/docs/bff/architecture/multi-frontend.md

@@ -35,7 +35,7 @@ There are some internal-facing applications that are exclusively used by interna
 
 There are also several public facing applications, that are used directly by customers. These users should be able to log in using their own identity, via providers like Google, Twitter, or others. This authentication process is handled by Duende IdentityServer. There is constant development ongoing on these applications and it's not uncommon for new applications to be introduced. There should be single sign-on across all these public facing applications. They are all available on the same domain name, but use path based routing to distinguish themselves, such as `https://app.example.com/app1`
 
-There is also a partner portal. This partner portal can only be accessed by employees of the partners. Each partner should be able to bring their own identity provider. This is implemented using the [Dynamic Providers](/identityserver/ui/login/dynamicproviders/) feature of Duende IdentityServer. 
+There is also a partner portal. This partner portal can only be accessed by employees of the partners. Each partner should be able to bring their own identity provider. This is implemented using the [Dynamic Providers](/identityserver/ui/login/dynamicproviders.md) feature of Duende IdentityServer. 
 
 This setup, with multiple frontends, each having different authentication requirements and different API surfaces, is now supported by the BFF. 
 
@@ -80,7 +80,7 @@ app.Run();
 
 ## Authentication Architecture
 
-When you use multiple frontends, you can't rely on [manual authentication configuration](../fundamentals/session/handlers.mdx#manually-configuring-authentication). This is because each frontend requires its own scheme, and potentially its own OpenID Connect and Cookie configuration. 
+When you use multiple frontends, you can't rely on [manual authentication configuration](/bff/fundamentals/session/handlers.mdx#manually-configuring-authentication). This is because each frontend requires its own scheme, and potentially its own OpenID Connect and Cookie configuration. 
 
 The BFF registers a dynamic authentication scheme, which automatically configures the OpenID Connect and Cookie Scheme's on behalf of the frontends. It does this using a custom `AuthenticationSchemeProvider` called `BffAuthenticationSchemeProvider` to return appropriate authentication schemes for each frontend. 
 

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

@@ -17,7 +17,7 @@ A couple of particularly notable OIDC flows that don't work for SPAs when third
 
 ## Session Management
 
-OIDC Session Management allows a client SPA to monitor the session at the OP by reading a cookie from the OP in a hidden iframe. If third party cookie blocking prevents the iframe from seeing that cookie, the SPA will not be able to monitor the session. The BFF solves this problem using [OIDC back-channel logout](/bff/fundamentals/session/management/back-channel-logout). 
+OIDC Session Management allows a client SPA to monitor the session at the OP by reading a cookie from the OP in a hidden iframe. If third party cookie blocking prevents the iframe from seeing that cookie, the SPA will not be able to monitor the session. The BFF solves this problem using [OIDC back-channel logout](/bff/fundamentals/session/management/back-channel-logout.md). 
 
 The BFF is able to operate server side, and is therefore able to have a back channel to the OP. When the session ends at the OP, it can send a back-channel message to the BFF, ending the session at the BFF.
 
@@ -28,9 +28,9 @@ Similarly to OIDC Session Management, OIDC Silent Login relies on a hidden ifram
 
 ### 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.
+The BFF supports silent login from the SPA with the /bff/silent-login [endpoint](/bff/fundamentals/session/management/silent-login.md). 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.
 
-If you need silent login with a third party OP, we recommend that you use the [Federation Gateway](/identityserver/ui/federation) pattern. In the federation gateway pattern, one identity provider (the gateway) federates with other remote identity providers. Because the client applications only interact with the gateway, the implementation details of the remote identity providers are abstracted. In this case, we shield the client application from the fact that the remote identity provider is a third party by hosting the gateway as a first party to the client. This makes the client application's requests for silent login always first party.
+If you need silent login with a third party OP, we recommend that you use the [Federation Gateway](/identityserver/ui/federation.md) pattern. In the federation gateway pattern, one identity provider (the gateway) federates with other remote identity providers. Because the client applications only interact with the gateway, the implementation details of the remote identity providers are abstracted. In this case, we shield the client application from the fact that the remote identity provider is a third party by hosting the gateway as a first party to the client. This makes the client application's requests for silent login always first party.
 
 
 ### Alternatives

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

@@ -66,7 +66,7 @@ the authentication cookie as normal.
 
 Effectively, this turns your front-end and BFF Host into two separately deployable units. You'll need to ensure that the
 two components are hosted on subdomains of the same domain so
-that [third party cookie blocking](/bff/architecture/third-party-cookies) doesn't prevent the frontend from including
+that [third party cookie blocking](/bff/architecture/third-party-cookies.md) doesn't prevent the frontend from including
 cookies in its requests to the BFF host.
 
 In order for this architecture to work, the following things are needed: