Configuring middleware in the component

daprdocs/content/en/developing-applications/develop-components/middleware-components/_index.md

@@ -0,0 +1,8 @@
+---
+type: docs
+title: "Middlware components"
+linkTitle: "Middleware components"
+description: "Guidance on how to work with middleware components"
+weight: 200
+---
+

daprdocs/content/en/developing-applications/develop-components/develop-middleware.md → daprdocs/content/en/developing-applications/develop-components/middleware-components/develop-middleware.md

@@ -1,12 +1,9 @@
 ---
 type: docs
 title: "How to: Author middleware components"
-linkTitle: "Middleware components"
-weight: 200
+linkTitle: "How to: Author middleware"
+weight: 100
 description: "Learn how to develop middleware components"
-aliases:
-  - /developing-applications/middleware/middleware-overview/
-  - /concepts/middleware-concept/
 ---
 
 Dapr allows custom processing pipelines to be defined by chaining a series of middleware components. In this guide, you'll learn how to create a middleware component. To learn how to configure an existing middleware component, see [Configure middleware components]({{< ref middleware.md >}})

daprdocs/content/en/operations/components/middleware.md

@@ -3,13 +3,19 @@ type: docs
 title: "Configure middleware components"
 linkTitle: "Configure middleware"
 weight: 2000
-description: "Customize processing pipelines by adding middleware components"
+description: "Customize processing pipelines via the middleware components"
 ---
 
-Dapr allows custom processing pipelines to be defined by chaining a series of middleware components. There are two places that you can use a middleware pipeline:
+{{% alert title="Note" color="primary" %}}
+Configuring middleware components using the [configuration schema]({{< ref configuration-schema.md >}}) is **deprecated**.
+{{% /alert %}}
+
+With Dapr, you can define custom processing pipelines by chaining a series of middleware components. There are two places that you can use a middleware pipeline:
 
 1. Building block APIs - HTTP middleware components are executed when invoking any Dapr HTTP APIs.
-2. Service-to-Service invocation - HTTP middleware components are applied to service-to-service invocation calls.
+1. Service-to-Service invocation - HTTP middleware components are applied to service-to-service invocation calls.
+
+In this guide, you learn how to configure middleware using its component YAML. To learn how to create middleware components, see the [Author middleware components how-to guides.]({{< ref develop-middleware.md >}}) 
 
 ## Configure API middleware pipelines
 
@@ -19,55 +25,57 @@ A request goes through all the defined middleware components before it's routed
 
 <img src="/images/middleware.png" width="800" alt="Diagram showing the flow of a request and a response through the middlewares, as described in the paragraph above" />
 
-HTTP middleware components are executed when invoking Dapr HTTP APIs using the `httpPipeline` configuration.
+HTTP middleware components are executed when invoking Dapr HTTP APIs using the `httpPipeline` setting.
 
-The following configuration example defines a custom pipeline that uses an [OAuth 2.0 middleware]({{< ref middleware-oauth2.md >}}) and an [uppercase middleware component]({{< ref middleware-uppercase.md >}}). In this case, all requests are authorized through the OAuth 2.0 protocol, and transformed to uppercase text, before they are forwarded to user code.
+The following example defines a custom pipeline that uses a [RouterChecker middleware]({{< ref middleware-routerchecker.md >}}). In this case, all requests are authorized against the `^[A-Za-z0-9/._-]+$`:regex before they are forwarded to user code. The `priority` field determines the order in which requests are executed once all handler components are collected.
 
 ```yaml
 apiVersion: dapr.io/v1alpha1
-kind: Configuration
+kind: Component
 metadata:
-  name: pipeline
-  namespace: default
+  name: routerchecker1
 spec:
-  httpPipeline:
-    handlers:
-      - name: oauth2
-        type: middleware.http.oauth2
-      - name: uppercase
-        type: middleware.http.uppercase
+  type: middleware.http.routerchecker
+  version: v1
+  metadata:
+  - name: rule
+    value: "^[A-Za-z0-9/._-]+$"
+  - name: pipelineType
+    value: httpPipeline
+  - name: priority
+    value: 1 
 ```
 
-As with other components, middleware components can be found in the [supported Middleware reference]({{< ref supported-middleware >}}) and in the [`dapr/components-contrib` repo](https://github.com/dapr/components-contrib/tree/master/middleware/http).
-
-{{< button page="supported-middleware" text="See all middleware components">}}
+As with other components, supported middleware components can be found in the [supported Middleware reference guide]({{< ref supported-middleware >}}) and in the [`dapr/components-contrib` repo](https://github.com/dapr/components-contrib/tree/master/middleware/http).
 
-## Configure app middleware pipelines
+## Configure app middleware
 
 You can also use any middleware component when making service-to-service invocation calls. For example, to add token validation in a zero-trust environment, to transform a request for a specific app endpoint, or to apply OAuth policies.
 
 Service-to-service invocation middleware components apply to all **outgoing** calls from a Dapr sidecar to the receiving application (service), as shown in the diagram below.
 
 <img src="/images/app-middleware.png" width="800" alt="Diagram showing the flow of a service invocation request. Requests from the callee Dapr sidecar to the callee application go through the app middleware pipeline as described in the paragraph above." />
 
-Any middleware component that can be used as HTTP middleware can also be applied to service-to-service invocation calls as a middleware component using the `appHttpPipeline` configuration. The example below adds the `uppercase` middleware component for all outgoing calls from the Dapr sidecar (target of service invocation) to the application that this configuration is applied to.
+Any middleware component that can be used as HTTP middleware can also be applied to service-to-service invocation calls as a middleware component using the `appHttpPipeline` configuration. The example below adds the `routerchecker` middleware component for all outgoing calls from the Dapr sidecar (target of service invocation) to the application that this configuration is applied to.
 
 ```yaml
 apiVersion: dapr.io/v1alpha1
-kind: Configuration
+kind: Component
 metadata:
-  name: pipeline
-  namespace: default
+  name: routerchecker1
 spec:
-  appHttpPipeline:
-    handlers:
-      - name: uppercase
-        type: middleware.http.uppercase
+  type: middleware.http.routerchecker
+  version: v1
+  metadata:
+  - name: rule
+    value: "^[A-Za-z0-9/._-]+$"
+  - name: pipelineType
+    value: appHttpPipeline
+  - name: priority
+    value: 1 
 ```
 
 ## Related links
 
 - [Learn how to author middleware components]({{< ref develop-middleware.md >}})
-- [Component schema]({{< ref component-schema.md >}})
-- [Configuration overview]({{< ref configuration-overview.md >}})
 - [API middleware sample](https://github.com/dapr/samples/tree/master/middleware-oauth-google)

daprdocs/content/en/reference/components-reference/supported-middleware/middleware-bearer.md

@@ -25,6 +25,10 @@ spec:
       value: "<your token audience; i.e. the application's client ID>"
     - name: issuer
       value: "<your token issuer, e.g. 'https://accounts.google.com'>"
+    - name: pipelineType
+      value: "httpPipeline"
+    - name: priority
+      value: "1"
 
     # Optional values
     - name: jwksURL
@@ -37,6 +41,8 @@ spec:
 |-------|:--------:|---------|---------|
 | `audience` | Y | The audience expected in the tokens. Usually, this corresponds to the client ID of your application that is created as part of a credential hosted by a OpenID Connect platform. | 
 | `issuer` | Y | The issuer authority, which is the value expected in the issuer claim in the tokens. | `"https://accounts.google.com"`
+| `pipelineType` | Y | For configuring middleware pipelines. One of the two types of middleware pipeline so you can configure your middleware for either sidecar-to-sidecar communication (`appHttpPipeline`) or sidecar-to-app communication (`httpPipeline`). | `"httpPipeline"`, `"appHttpPipeline"`
+| `priority` | Y | For configuring middleware pipeline ordering. The order in which [middleware components]({{< ref middleware.md >}}) should be arranged and executed. | `"1"`
 | `jwksURL` | N | Address of the JWKS (JWK Set containing the public keys for verifying tokens). If empty, will try to fetch the URL set in the OpenID Configuration document `<issuer>/.well-known/openid-configuration`.  | `"https://accounts.google.com/.well-known/openid-configuration"`
 
 Common values for `issuer` include:
@@ -48,19 +54,7 @@ Common values for `issuer` include:
 
 ## Dapr configuration
 
-To be applied, the middleware must be referenced in [configuration]({{< ref configuration-concept.md >}}). See [middleware pipelines]({{< ref "middleware.md">}}).
-
-```yaml
-apiVersion: dapr.io/v1alpha1
-kind: Configuration
-metadata:
-  name: appconfig
-spec:
-  httpPipeline:
-    handlers:
-    - name: bearer-token
-      type: middleware.http.bearer
-```
+You can apply the middleware configuration directly in the middleware component. See [how to apply middleware pipeline configurations]({{< ref "middleware.md" >}}).
 
 ## Related links
 

daprdocs/content/en/reference/components-reference/supported-middleware/middleware-oauth2.md

@@ -36,6 +36,10 @@ spec:
     value: "authorization"
   - name: forceHTTPS
     value: "false"
+  - name: pipelineType
+    value: "httpPipeline"
+  - name: priority
+    value: "1"
 ```
 
 {{% alert title="Warning" color="warning" %}}
@@ -46,30 +50,20 @@ The above example uses secrets as plain strings. It is recommended to use a secr
 
 | Field | Details | Example |
 |-------|---------|---------|
-| clientId | The client ID of your application that is created as part of a credential hosted by a OAuth-enabled platform
-| clientSecret | The client secret of your application that is created as part of a credential hosted by a OAuth-enabled platform
-| scopes | A list of space-delimited, case-sensitive strings of [scopes](https://tools.ietf.org/html/rfc6749#section-3.3) which are typically used for authorization in the application | `"https://www.googleapis.com/auth/userinfo.email"`
-| authURL | The endpoint of the OAuth2 authorization server | `"https://accounts.google.com/o/oauth2/v2/auth"`
-| tokenURL | The endpoint is used by the client to obtain an access token by presenting its authorization grant or refresh token | `"https://accounts.google.com/o/oauth2/token"`
-| redirectURL | The URL of your web application that the authorization server should redirect to once the user has authenticated | `"https://myapp.com"`
-| authHeaderName | The authorization header name to forward to your application | `"authorization"`
+| `clientId` | The client ID of your application that is created as part of a credential hosted by a OAuth-enabled platform
+| `clientSecret` | The client secret of your application that is created as part of a credential hosted by a OAuth-enabled platform
+| `scopes` | A list of space-delimited, case-sensitive strings of [scopes](https://tools.ietf.org/html/rfc6749#section-3.3) which are typically used for authorization in the application | `"https://www.googleapis.com/auth/userinfo.email"`
+| `authURL` | The endpoint of the OAuth2 authorization server | `"https://accounts.google.com/o/oauth2/v2/auth"`
+| `tokenURL` | The endpoint is used by the client to obtain an access token by presenting its authorization grant or refresh token | `"https://accounts.google.com/o/oauth2/token"`
+| `redirectURL` | The URL of your web application that the authorization server should redirect to once the user has authenticated | `"https://myapp.com"`
+| `authHeaderName` | The authorization header name to forward to your application | `"authorization"`
 | forceHTTPS | If true, enforces the use of TLS/SSL | `"true"`,`"false"`                                           |
+| `pipelineType` | For configuring middleware pipelines. One of the two types of middleware pipeline so you can configure your middleware for either sidecar-to-sidecar communication (`appHttpPipeline`) or sidecar-to-app communication (`httpPipeline`). | `"httpPipeline"`, `"appHttpPipeline"`
+| `priority` | For configuring middleware pipeline ordering. The order in which [middleware components]({{< ref middleware.md >}}) should be arranged and executed. | `"1"`
 
 ## Dapr configuration
 
-To be applied, the middleware must be referenced in [configuration]({{< ref configuration-concept.md >}}). See [middleware pipelines]({{< ref "middleware.md#customize-processing-pipeline">}}).
-
-```yaml
-apiVersion: dapr.io/v1alpha1
-kind: Configuration
-metadata:
-  name: appconfig
-spec:
-  httpPipeline:
-    handlers:
-    - name: oauth2
-      type: middleware.http.oauth2
-```
+You can apply the middleware configuration directly in the middleware component. See [how to apply middleware pipeline configurations]({{< ref "middleware.md" >}}).
 
 ## Related links
 

daprdocs/content/en/reference/components-reference/supported-middleware/middleware-oauth2clientcredentials.md

@@ -30,6 +30,10 @@ spec:
     value: "https://accounts.google.com/o/oauth2/token"
   - name: headerName
     value: "authorization"
+  - name: pipelineType
+    value: "httpPipeline"
+  - name: priority
+    value: "1"
 ```
 
 {{% alert title="Warning" color="warning" %}}
@@ -40,13 +44,16 @@ The above example uses secrets as plain strings. It is recommended to use a secr
 
 | Field      | Details | Example |
 |------------|---------|---------|
-| clientId | The client ID of your application that is created as part of a credential hosted by a OAuth-enabled platform
-| clientSecret | The client secret of your application that is created as part of a credential hosted by a OAuth-enabled platform
-| scopes | A list of space-delimited, case-sensitive strings of [scopes](https://tools.ietf.org/html/rfc6749#section-3.3) which are typically used for authorization in the application | `"https://www.googleapis.com/auth/userinfo.email"`
-| tokenURL | The endpoint is used by the client to obtain an access token by presenting its authorization grant or refresh token | `"https://accounts.google.com/o/oauth2/token"`
-| headerName | The authorization header name to forward to your application | `"authorization"`
-| endpointParamsQuery | Specifies additional parameters for requests to the token endpoint | `true`
-| authStyle | Optionally specifies how the endpoint wants the client ID & client secret sent. See the table of possible values below | `0`
+| `clientId` | The client ID of your application that is created as part of a credential hosted by a OAuth-enabled platform
+| `clientSecret` | The client secret of your application that is created as part of a credential hosted by a OAuth-enabled platform
+| `scopes` | A list of space-delimited, case-sensitive strings of [scopes](https://tools.ietf.org/html/rfc6749#section-3.3) which are typically used for authorization in the application | `"https://www.googleapis.com/auth/userinfo.email"`
+| `tokenURL` | The endpoint is used by the client to obtain an access token by presenting its authorization grant or refresh token | `"https://accounts.google.com/o/oauth2/token"`
+| `headerName` | The authorization header name to forward to your application | `"authorization"`
+| `endpointParamsQuery` | Specifies additional parameters for requests to the token endpoint | `true`
+| `authStyle` | Optionally specifies how the endpoint wants the client ID & client secret sent. See the table of possible values below | `0`
+| `pipelineType` | For configuring middleware pipelines. One of the two types of middleware pipeline so you can configure your middleware for either sidecar-to-sidecar communication (`appHttpPipeline`) or sidecar-to-app communication (`httpPipeline`). | `"httpPipeline"`, `"appHttpPipeline"`
+| `priority` | For configuring middleware pipeline ordering. The order in which [middleware components]({{< ref middleware.md >}}) should be arranged and executed. | `"1"`
+
 
 ### Possible values for `authStyle`
 
@@ -58,19 +65,7 @@ The above example uses secrets as plain strings. It is recommended to use a secr
 
 ## Dapr configuration
 
-To be applied, the middleware must be referenced in a [configuration]({{< ref configuration-concept.md >}}). See [middleware pipelines]({{< ref "middleware.md#customize-processing-pipeline">}}).
-
-```yaml
-apiVersion: dapr.io/v1alpha1
-kind: Configuration
-metadata:
-  name: appconfig
-spec:
-  httpPipeline:
-    handlers:
-    - name: oauth2clientcredentials
-      type: middleware.http.oauth2clientcredentials
-```
+You can apply the middleware configuration directly in the middleware component. See [how to apply middleware pipeline configurations]({{< ref "middleware.md" >}}).
 
 ## Related links
 - [Middleware]({{< ref middleware.md >}})

daprdocs/content/en/reference/components-reference/supported-middleware/middleware-opa.md

@@ -69,6 +69,12 @@ spec:
             [_, jwt] := split(auth_header, " ")
             [_, payload, _] := io.jwt.decode(jwt)
         }
+
+    # Configure middleware pipelines
+    - name: pipelineType
+      value: "httpPipeline"
+    - name: priority
+      value: "1"
 ```
 
 You can prototype and experiment with policies using the [official OPA playground](https://play.openpolicyagent.org). For example, [you can find the example policy above here](https://play.openpolicyagent.org/p/oRIDSo6OwE).
@@ -81,22 +87,12 @@ You can prototype and experiment with policies using the [official OPA playgroun
 | `defaultStatus`   | The status code to return for denied responses | `"https://accounts.google.com"`, `"https://login.salesforce.com"`
 | `readBody`   | If set to `true` (the default value), the body of each request is read fully in-memory and can be used to make policy decisions. If your policy doesn't depend on inspecting the request body, consider disabling this (setting to `false`) for significant performance improvements. | `"false"`
 | `includedHeaders` | A comma-separated set of case-insensitive headers to include in the request input. Request headers are not passed to the policy by default. Include to receive incoming request headers in the input | `"x-my-custom-header, x-jwt-header"`
+| `pipelineType` | For configuring middleware pipelines. One of the two types of middleware pipeline so you can configure your middleware for either sidecar-to-sidecar communication (`appHttpPipeline`) or sidecar-to-app communication (`httpPipeline`). | `"httpPipeline"`, `"appHttpPipeline"`
+| `priority` | For configuring middleware pipeline ordering. The order in which [middleware components]({{< ref middleware.md >}}) should be arranged and executed. | `"1"`
 
 ## Dapr configuration
 
-To be applied, the middleware must be referenced in [configuration]({{< ref configuration-concept.md >}}). See [middleware pipelines]({{< ref "middleware.md#customize-processing-pipeline">}}).
-
-```yaml
-apiVersion: dapr.io/v1alpha1
-kind: Configuration
-metadata:
-  name: appconfig
-spec:
-  httpPipeline:
-    handlers:
-    - name: my-policy
-      type: middleware.http.opa
-```
+You can apply the middleware configuration directly in the middleware component. See [how to apply middleware pipeline configurations]({{< ref "middleware.md" >}}).
 
 ## Input