Remove csharp language from code blocks

In the latest version of hugo, there is a bug where csharp code blocks
indentation is broken, but if you allow hugo to infer the language,
indentation works (and the inferred syntax highlighting seems correct
too, somehow).

IdentityServer/v6/docs/content/apis/add_apis.md

@@ -15,7 +15,7 @@ You could achieve the same by using either Microsoft's *JwtBearer* handler. But
 
 Start by registering your API as an *ApiScope*, (or resource) e.g.:
 
-```cs
+```
 var scopes = new List<ApiScope>
 {
     // local API
@@ -25,7 +25,7 @@ var scopes = new List<ApiScope>
 
 ..and give your clients access to this API, e.g.:
 
-```cs
+```
 new Client
 {
     // rest omitted
@@ -39,21 +39,21 @@ The value of *IdentityServerConstants.LocalApi.ScopeName* is *IdentityServerApi*
 
 To enable token validation for local APIs, add the following to your IdentityServer startup:
 
-```cs
+```
 services.AddLocalApiAuthentication();
 ```
 
 To protect an API controller, decorate it with an *Authorize* attribute using the *LocalApi.PolicyName* policy:
 
-```cs
+```
 [Route("localApi")]
 [Authorize(LocalApi.PolicyName)]
 public class LocalApiController : ControllerBase
 {
-    public IActionResult Get()
-    {
-        // omitted
-    }
+	public IActionResult Get()
+	{
+		// omitted
+	}
 }
 ```
 
@@ -62,7 +62,7 @@ Authorized clients can then request a token for the *IdentityServerApi* scope an
 ## Discovery
 You can also add your endpoints to the discovery document if you want, e.g like this::
 
-```cs
+```
 services.AddIdentityServer(options =>
 {
     options.Discovery.CustomEntries.Add("local_api", "~/localapi");
@@ -83,7 +83,7 @@ This covers the most common scenarios. You can customize this behavior in the fo
 * Do your own scope validation/authorization in your controllers using custom policies or code, e.g.:
 
 
-```cs
+```
     services.AddAuthorization(options =>
     {
         options.AddPolicy(IdentityServerConstants.LocalApi.PolicyName, policy =>
@@ -99,7 +99,7 @@ This covers the most common scenarios. You can customize this behavior in the fo
 You can provide a callback to transform the claims of the incoming token after validation.
 Either use the helper method, e.g.:
 
-```cs
+```
 services.AddLocalApiAuthentication(principal =>
 {
     principal.Identities.First().AddClaim(new Claim("additional_claim", "additional_value"));

IdentityServer/v6/docs/content/apis/aspnetcore/authorization.md

@@ -8,7 +8,7 @@ The access token will include additional claims that can be used for authorizati
 
 In ASP.NET core, the contents of the JWT payload get transformed into claims and packaged up in a *ClaimsPrincipal*. So you can always write custom validation or authorization logic in C#:
 
-```cs
+```
 public IActionResult Get()
 {
     var isAllowed = User.HasClaim("scope", "read");
@@ -21,7 +21,7 @@ For better encapsulation and re-use, consider using the ASP.NET Core [authorizat
 
 With this approach, you would first turn the claim requirement(s) into a named policy:
 
-```cs
+```
 public void ConfigureServices(IServiceCollection services)
 {
     services.AddAuthorization(options =>
@@ -34,7 +34,7 @@ public void ConfigureServices(IServiceCollection services)
 
 ..and then enforce it, e.g. using the routing table:
 
-```cs
+```
     app.UseEndpoints(endpoints =>
     {
         endpoints.MapControllers().RequireAuthorization("read_access");
@@ -43,7 +43,7 @@ public void ConfigureServices(IServiceCollection services)
 
 ...or imperatively inside the controller:
 
-```cs
+```
 public class DataController : ControllerBase
 {
     IAuthorizationService _authz;
@@ -64,7 +64,7 @@ public class DataController : ControllerBase
 
 ... or declaratively:
 
-```cs
+```
 public class DataController : ControllerBase
 {
     [Authorize("read_access")]
@@ -82,7 +82,7 @@ Historically, Duende IdentityServer emitted the *scope* claims as an array in th
 
 The newer *JWT Profile for OAuth* [spec]({{< ref "/overview/specs" >}}) mandates that the scope claim is a single space delimited string. You can switch the format by setting the *EmitScopesAsSpaceDelimitedStringInJwt* on the [options]({{< ref "/reference/options" >}}). But this means that the code consuming access tokens might need to be adjusted. The following code can do a conversion to the *multiple claims* format that .NET prefers:
 
-```cs
+```
 namespace IdentityModel.AspNetCore.AccessTokenValidation
 {
     /// <summary>

IdentityServer/v6/docs/content/apis/aspnetcore/confirmation.md

@@ -12,7 +12,7 @@ If you are using a [mutual TLS connection]({{< ref "/tokens/pop/mtls" >}}) to es
 
 You can do so with custom middleware like this:
 
-```cs
+```
 public void Configure(IApplicationBuilder app)
 {
     // rest omitted
@@ -31,7 +31,7 @@ public void Configure(IApplicationBuilder app)
 
 Here, *UseConfirmationValidation* is an extension method that registers the middleware that performs the necessary validation:
 
-```cs
+```
 public static class ConfirmationValidationExtensions
 {
     public static IApplicationBuilder UseConfirmationValidation(this IApplicationBuilder app, ConfirmationValidationMiddlewareOptions options = default)
@@ -43,7 +43,7 @@ public static class ConfirmationValidationExtensions
 
 And this is the actual middleware that validates the *cnf* claim:
 
-```cs
+```
 // this middleware validates the cnf claim (if present) against the thumbprint of the X.509 client certificate for the current client
 public class ConfirmationValidationMiddleware
 {
@@ -117,7 +117,7 @@ DPoP proof token processing involves requiring the DPoP scheme on the authorizat
 Given that there are no off-the-shelf libraries that implement this, we have developed a full-featured sample implementation.
 With this sample the configuration necessary in your startup can be as simple as this:
 
-```cs
+```
 
 public void ConfigureServices(IServiceCollection services)
 {

IdentityServer/v6/docs/content/apis/aspnetcore/jwt.md

@@ -15,7 +15,7 @@ First you need to add a reference to the authentication handler in your API proj
 
 If all you care about is making sure that an access token comes from your trusted IdentityServer, the following snippet shows the typical JWT validation configuration for ASP.NET Core:
 
-```cs
+```
 public class Startup
 {
     public void ConfigureServices(IServiceCollection services)
@@ -65,7 +65,7 @@ If you designed your APIs around the concept of [API resources]({{< ref "/fundam
 
 If you want to express in your API, that only access tokens for the *api1* audience (aka API resource name) are accepted, change the above code snippet to:
 
-```cs
+```
 public class Startup
 {
     public void ConfigureServices(IServiceCollection services)

IdentityServer/v6/docs/content/apis/aspnetcore/reference.md

@@ -6,7 +6,7 @@ weight: 20
 
 If you are using [reference tokens]({{< ref "/tokens/reference" >}}), you need an authentication handler that implements the back-channel validation via the [OAuth 2.0 token introspection](https://tools.ietf.org/html/rfc7662) protocol, e.g. [this](https://github.com/IdentityModel/IdentityModel.AspNetCore.OAuth2Introspection) one:.
 
-```cs
+```
 services.AddAuthentication("token")
     .AddOAuth2Introspection("token", options =>
     {
@@ -21,7 +21,7 @@ services.AddAuthentication("token")
 ## Supporting both JWTs and reference tokens
 It is not uncommon to use the same API with both JWTs and reference tokens. In this case you setup two authentication handlers, make one the default handler and provide some forwarding logic, e.g.:
 
-```cs
+```
 services.AddAuthentication("token")
 
     // JWT tokens
@@ -48,7 +48,7 @@ services.AddAuthentication("token")
 
 The logic of the forward selector looks like this:
 
-```cs
+```
 /// <summary>
 /// Provides a forwarding func for JWT vs reference tokens (based on existence of dot in token)
 /// </summary>

IdentityServer/v6/docs/content/bff/apis/local.md

@@ -21,7 +21,7 @@ Alternatively, you can make the data available as a service and make HTTP reques
 Your local endpoints can leverage services like the HTTP client factory and Duende.BFF [token management]({{< ref "/bff/tokens" >}}) to make the outgoing calls. The following is a simplified example showing how local endpoints can obtain managed access tokens and use them to make requests to remote APIs.
 
 
-```cs
+```
 [Route("myApi")]
 public class MyApiController : ControllerBase
 {
@@ -82,7 +82,7 @@ Duende.BFF can automate both the pre-processing step of requiring the custom ant
 #### Add Middleware
 Add the BFF middleware to the pipeline by calling *UseBFF*. Note that the  middleware must be placed before the authorization middleware, but after routing.
 
-```csharp
+```
 public void Configure(IApplicationBuilder app)
 {
     // rest omitted
@@ -102,22 +102,22 @@ public void Configure(IApplicationBuilder app)
 Endpoints that require the pre and post processing described above must be decorated with a call to *AsBffApiEndpoint()*.
 
 For minimal API endpoints, you can apply BFF pre- and post-processing when they are mapped.
-```csharp
+```
 endpoints.MapPost("/foo", context => { ... })
     .RequireAuthorization()  // no anonymous access
     .AsBffApiEndpoint();     // BFF pre/post processing
 ```
 
 
 For MVC controllers, you can similarly apply BFF pre- and post-processing to controller actions when they are mapped.
-```csharp
+```
 endpoints.MapControllers()
     .RequireAuthorization()  // no anonymous access
     .AsBffApiEndpoint();     // BFF pre/post processing
 ```
 
 Alternatively, you can apply the *[BffApi]* attribute directly to the controller or action.
-```csharp
+```
 [Route("myApi")]
 [BffApi]
 public class MyApiController : ControllerBase
@@ -132,7 +132,7 @@ However, if you are defending against CSRF attacks with some other mechanism, yo
 
 For *version 1.x*, set the *requireAntiForgeryCheck* parameter to *false* when adding the endpoint. For example:
 
-```csharp
+```
 app.UseEndpoints(endpoints =>
 {
     // MVC controllers
@@ -153,7 +153,7 @@ app.UseEndpoints(endpoints =>
 
 On MVC controllers and actions you can set the *RequireAntiForgeryCheck* as a flag in the *BffApiAttribute*, like this:
 
-```csharp
+```
 [Route("sample")]
 // WARNING: Disabling antiforgery protection may make
 // your APIs vulnerable to CSRF attacks
@@ -165,7 +165,7 @@ public class SampleApiController : ControllerBase
 
 In *version 2.x*, use the *SkipAntiforgery* fluent API when adding the endpoint. For example:
 
-```csharp
+```
 app.UseEndpoints(endpoints =>
 {
     // MVC controllers
@@ -188,7 +188,7 @@ app.UseEndpoints(endpoints =>
 
 MVC controllers and actions can use the *BffApiSkipAntiforgeryAttribute* (which is independent of the *BffApiAttribute*), like this:
 
-```csharp
+```
 [Route("sample")]
 // WARNING: Disabling antiforgery protection may make
 // your APIs vulnerable to CSRF attacks

IdentityServer/v6/docs/content/bff/apis/remote.md

@@ -17,7 +17,7 @@ To enable this feature, add a reference to the *Duende.BFF.Yarp* Nuget package,
 
 #### Add Remote API Service to DI
 
-```cs
+```
 services.AddBff()
     .AddRemoteApis();
 ```
@@ -26,7 +26,7 @@ services.AddBff()
 #### Map Remote APIs
 This example routes a local */api/customers* endpoint to a remote API, and forwards the user's access token in the outgoing call:
 
-```cs
+```
 app.UseEndpoints(endpoints =>
 {
     endpoints.MapRemoteBffApiEndpoint(

IdentityServer/v6/docs/content/bff/apis/yarp.md

@@ -10,7 +10,7 @@ YARP includes many advanced features such as load balancing, service discovery,
 #### Adding YARP
 To enable Duende.BFF's YARP integration, add a reference to the *Duende.BFF.Yarp* Nuget package to your project and add YARP and the BFF's YARP extensions to DI:
 
-```cs
+```
 services.AddBff();
 
 // adds YARP with BFF extensions
@@ -48,7 +48,7 @@ See the Microsoft [documentation](https://microsoft.github.io/reverse-proxy/arti
 
 Another option is to configure YARP in code using the in-memory config provider included in the BFF extensions for YARP. The above configuration as code would look like this:
 
-```cs
+```
 builder.LoadFromMemory(
     new[]
     {
@@ -108,7 +108,7 @@ Routes that set the *Duende.Bff.Yarp.TokenType* metadata **require** the given t
 
 If you are using the code config method, call the *WithAccessToken* extension method to achieve the same thing:
 
-```cs
+```
 builder.LoadFromMemory(
     new[]
     {
@@ -153,7 +153,7 @@ This metadata causes the user's access token to be sent with the proxied request
 
 If you are using the code config method, call the *WithOptionalUserAccessToken* extension method to achieve the same thing:
 
-```cs
+```
 builder.LoadFromMemory(
     new[]
     {
@@ -185,7 +185,7 @@ The value of the header is not important, but its presence, combined with the co
 
 You can add the anti-forgery protection to all YARP routes by calling the *AsBffApiEndpoint* extension method:
 
-```cs
+```
 endpoints.MapReverseProxy()
     .AsBffApiEndpoint();
 
@@ -214,7 +214,7 @@ If you need more fine grained control over which routes should enforce the anti-
 
 This is also possible in code:
 
-```cs
+```
 builder.LoadFromMemory(
     new[]
     {
@@ -239,7 +239,7 @@ You can combine the token management feature with the anti-forgery check.
 
 To enforce the presence of the anti-forgery headers, you need to add a middleware to the YARP pipeline:
 
-```cs
+```
 endpoints.MapReverseProxy(proxyApp =>
 {
     proxyApp.UseAntiforgeryCheck();