Merge branch 'v1.3' into daprd-doc

daprdocs/content/en/developing-applications/building-blocks/pubsub/howto-publish-subscribe.md

@@ -416,6 +416,10 @@ app.post('/dsstatus', (req, res) => {
 
 {{< /tabs >}}
 
+{{% alert title="Note on message redelivery" color="primary" %}}
+Some pubsub components (e.g. Redis) will redeliver a message if a response is not sent back within a specified time window. Make sure to configure metadata such as `processingTimeout` to customize this behavior. For more information refer to the respective [component references]({{< ref supported-pubsub >}}).
+{{% /alert %}}
+
 ## (Optional) Step 5: Publishing a topic with code
 
 {{< tabs Node PHP>}}

daprdocs/content/en/developing-applications/building-blocks/pubsub/pubsub-overview.md

@@ -93,7 +93,7 @@ Similarly, if two different applications (different app-IDs) subscribe to the sa
 
 ### Topic scoping
 
-By default, all topics backing the Dapr pub/sub component (e.g. Kafka, Redis Stream, RabbitMQ) are available to every application configured with that component. To limit which application can publish or subscribe to topics, Dapr provides topic scoping. This enables to you say which topics an application is allowed to published and which topics an application is allowed to subscribed to. For more information read [publish/subscribe topic scoping]({{< ref pubsub-scopes.md >}}).
+By default, all topics backing the Dapr pub/sub component (e.g. Kafka, Redis Stream, RabbitMQ) are available to every application configured with that component. To limit which application can publish or subscribe to topics, Dapr provides topic scoping. This enables to you say which topics an application is allowed to publish and which topics an application is allowed to subscribe to. For more information read [publish/subscribe topic scoping]({{< ref pubsub-scopes.md >}}).
 
 ### Message Time-to-Live (TTL)
 Dapr can set a timeout message on a per message basis, meaning that if the message is not read from the pub/sub component, then the message is discarded. This is to prevent the build up of messages that are not read. A message that has been in the queue for longer than the configured TTL is said to be dead.  For more information read [publish/subscribe message time-to-live]({{< ref pubsub-message-ttl.md >}}).

daprdocs/content/en/developing-applications/building-blocks/state-management/state-store-ttl.md

@@ -21,7 +21,7 @@ When a TTL is not specified the default behavior of the state store is retained.
 
 ## Persisting state (ignoring an existing TTL)
 
-To explictly persist a state (ignoring any TTLs set for the key), specify a `ttlInSeconds` value of `-1`.
+To explicitly persist a state (ignoring any TTLs set for the key), specify a `ttlInSeconds` value of `-1`.
 
 ## Supported components
 

daprdocs/content/en/getting-started/configure-state-pubsub.md

@@ -125,6 +125,9 @@ spec:
     secretKeyRef:
       name: redis
       key: redis-password
+  # uncomment below for connecting to redis cache instances over TLS (ex - Azure Redis Cache)
+  # - name: enableTLS
+  #   value: true 
 ```
 
 This example uses the kubernetes secret that was created when setting up a cluster with the above instructions.
@@ -153,6 +156,9 @@ spec:
     secretKeyRef:
       name: redis
       key: redis-password
+ # uncomment below for connecting to redis cache instances over TLS (ex - Azure Redis Cache)
+  # - name: enableTLS
+  #   value: true 
 ```
 
 This example uses the kubernetes secret that was created when setting up a cluster with the above instructions.
@@ -179,6 +185,9 @@ spec:
     value: <HOST>
   - name: redisPassword
     value: <PASSWORD>
+  # uncomment below for connecting to redis cache instances over TLS (ex - Azure Redis Cache)
+  # - name: enableTLS
+  #   value: true 
 ```
 
 ```yaml
@@ -195,6 +204,9 @@ spec:
     value: <HOST>
   - name: redisPassword
     value: <PASSWORD>
+  # uncomment below for connecting to redis cache instances over TLS (ex - Azure Redis Cache)
+  # - name: enableTLS
+  #   value: true 
 ```
 
 ## Apply the configuration

daprdocs/content/en/reference/components-reference/supported-bindings/smtp.md

@@ -42,6 +42,8 @@ spec:
     value: "bcc@example.com"
   - name: subject
     value: "subject"
+  - name: priority
+    value: "[value 1-5]"
 ```
 
 {{% alert title="Warning" color="warning" %}}
@@ -62,6 +64,7 @@ The example configuration shown above, contain a username and password as plain-
 | emailCc | N | Output | If set, this specifies the email address to CC in. See [also](#example-request) | `"me@example.com"` |
 | emailBcc | N | Output | If set, this specifies email address to BCC in. See [also](#example-request) | `"me@example.com"` |
 | subject | N | Output | If set, this specifies the subject of the email message. See [also](#example-request) | `"subject of mail"` |
+| priority | N | Output | If set, this specifies the priority (X-Priority) of the email message, from 1 (lowest) to 5 (highest) (default value: 3). See [also](#example-request) | `"1"` |
 
 ## Binding support
 
@@ -78,6 +81,7 @@ You can specify any of the following optional metadata properties with each requ
 - `emailCC`
 - `emailBCC`
 - `subject`
+- `priority`
 
 When sending an email, the metadata in the configuration and in the request is combined. The combined set of metadata must contain at least the `emailFrom`, `emailTo` and `subject` fields.
 
@@ -90,7 +94,8 @@ Example:
   "metadata": {
     "emailTo": "dapr-smtp-binding@example.net",
     "emailCC": "cc1@example.net; cc2@example.net",
-    "subject": "Email subject"
+    "subject": "Email subject",
+    "priority: "1"
   },
   "data": "Testing Dapr SMTP Binding"
 }

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

@@ -61,7 +61,7 @@ spec:
             my_claim := jwt.payload["my-claim"]
         }
         jwt = { "payload": payload } {
-            auth_header := input.request.headers["authorization"]
+            auth_header := input.request.headers["Authorization"]
             [_, jwt] := split(auth_header, " ")
             [_, payload, _] := io.jwt.decode(jwt)
         }