Clarify usage of secrets in docs

docs/docs/20-usage/40-secrets.md

@@ -17,27 +17,72 @@ In this example, the secret named `secret_token` would be passed to the setting
 
 ```diff
  steps:
-   - name: docker
-     image: my-plugin
-+    environment:
-+      TOKEN_ENV:
-+        from_secret: secret_token
+   - name: 'plugin step'
+     image: registry/repo/image:tag
 +    settings:
 +      token:
++        from_secret: secret_token
+
+   - name: 'some commands using secrets'
+     image: bash
+     commands:
+       - env | grep TOKEN
++    environment:
++      TOKEN_ENV:
 +        from_secret: secret_token
 ```
 
+:::info Important
+Avoid using the deprecated `secrets` or `environment` fields in plugin steps.
+These options can potentially impact plugin execution and integrity.
+Instead, provide secrets via the `settings` field, preferably using the `from_secret` syntax (see below).
+
+This rule is also enforced by the pipeline linter to promote safe and predictable plugin behavior.
+:::
+
+In the example below, the secret `SURGE_TOKEN` would be passed to the setting named `surge_token`, which will be available in the plugin as an environment variable named `PLUGIN_SURGE_TOKEN` (See [plugins](./51-plugins/20-creating-plugins.md#settings) for details).
+
+```yaml
+steps:
+  - name: deploy-preview:
+    image: woodpeckerci/plugin-surge-preview
+    settings:
+      path: 'docs/build/'
+      surge_token:
+        from_secret: SURGE_TOKEN
+```
+
+As settings can have complex structures, `from_secret` is supported at any level:
+
+```yaml
+steps:
+  - name: deploy-test:
+    image: plugin-example
+    settings:
+      path: 'artifacts'
+      simple_token:
+        from_secret: A_TOKEN
+      advanced_setting:
+        items:
+          - "value1"
+          - some:
+              from_secret: secret_value
+          - "value3"
+```
+
+This method ensures flexible and secure use of secrets within plugin settings, while preserving the integrity and security of the plugin execution environment.
+
 ### Note about parameter pre-processing
 
 Please note parameter expressions are subject to pre-processing. When using secrets in parameter expressions they should be escaped.
 
 ```diff
  steps:
-   - name: docker
-     image: docker
+   - name: "step name"
+     image: registry/repo/image:tag
      commands:
--      - echo ${TOKEN_ENV}
-+      - echo $${TOKEN_ENV}
+-      - echo ${TOKEN}
++      - echo $${TOKEN}
      environment:
        TOKEN_ENV:
          from_secret: secret_token

docs/versioned_docs/version-2.7/20-usage/40-secrets.md

@@ -18,32 +18,66 @@ once their usage is declared in the `secrets` section:
 
 ```diff
  steps:
-   - name: docker
-     image: docker
+   - name: "step name"
+     image: registry/repo/image:tag
      commands:
-+      - echo $docker_username
-+      - echo $DOCKER_PASSWORD
-+    secrets: [ docker_username, DOCKER_PASSWORD ]
++      - echo $some_username
++      - echo $SOME_PASSWORD
++    secrets: [ some_username, SOME_PASSWORD ]
 ```
 
-The case of the environment variables is not changed, but secret matching is done case-insensitively. In the example above, `DOCKER_PASSWORD` would also match if the secret is called `docker_password`.
+The environment variables retain their original case, but secret matching is performed in a case-insensitive manner.
+In this example, `DOCKER_PASSWORD` would still match even if the secret is named `docker_password`.
 
-### Use secrets in settings and environment
+### Use secrets in normal steps via environment
 
-You can set an setting or environment value from secrets using the `from_secret` syntax.
-
-In this example, the secret named `secret_token` would be passed to the setting named `token`,which will be available in the plugin as environment variable named `PLUGIN_TOKEN` (See [plugins](./51-plugins/20-creating-plugins.md#settings) for details), and to the environment variable `TOKEN_ENV`.
+You can set an environment value from secrets using the `from_secret` syntax.
+So the secret key and environment variable name can differ.
 
 ```diff
  steps:
-   - name: docker
-     image: my-plugin
+   - name: test
+     image: bash
+     commands:
+       - env | grep OWN
+-    secrets: [ some_username, SOME_PASSWORD ]
 +    environment:
-+      TOKEN_ENV:
-+        from_secret: secret_token
-+    settings:
-+      token:
-+        from_secret: secret_token
++      SOME_OWN_DEFINED_VAR:
++        from_secret: some_username
+```
+
+### Use secrets in plugins via settings
+
+The `from_secret` syntax also work for settings in any hierarchy.
+
+In this example, the secret named `secret_token` would be passed to the setting named `SURGE_TOKEN`,which will be available in the plugin as environment variable named `PLUGIN_SURGE_TOKEN` (See [plugins](./51-plugins/20-creating-plugins.md#settings) for details).
+
+```diff
+ steps:
+   - name: deploy-preview:
+     image: woodpeckerci/plugin-surge-preview
+     settings:
+       path: 'docs/build/'
++      surge_token:
++        from_secret: SURGE_TOKEN
+```
+
+As settings can have complex structure, the `from_secret` is supported in all of it:
+
+```yaml
+steps:
+  - name: deploy-test:
+    image: plugin-example
+    settings:
+      path: 'artifacts'
+      simple_token:
+        from_secret: A_TOKEN
+      advanced:
+        items:
+          - "value1"
+          - some:
+              from_secret: secret_value
+          - "value3"
 ```
 
 ### Note about parameter pre-processing
@@ -52,14 +86,14 @@ Please note parameter expressions are subject to pre-processing. When using secr
 
 ```diff
  steps:
-   - name: docker
-     image: docker
+   - name: "echo password"
+     image: bash
      commands:
--      - echo ${docker_username}
--      - echo ${DOCKER_PASSWORD}
-+      - echo $${docker_username}
-+      - echo $${DOCKER_PASSWORD}
-     secrets: [ docker_username, DOCKER_PASSWORD ]
+-      - echo ${some_username}
+-      - echo ${SOME_PASSWORD}
++      - echo $${some_username}
++      - echo $${SOME_PASSWORD}
+     secrets: [ some_username, SOME_PASSWORD ]
 ```
 
 ### Use in Pull Requests events
@@ -70,9 +104,11 @@ Secrets are not exposed to pull requests by default. You can override this behav
 Please be careful when exposing secrets to pull requests. If your repository is open source and accepts pull requests your secrets are not safe. A bad actor can submit a malicious pull request that exposes your secrets.
 :::
 
-## Image filter
+## Plugins filter
+
+To prevent abusing your secrets from malicious usage, you can limit a secret to a list of plugins. If enabled they are not available to any other plugin (steps without user-defined commands). If you or an attacker defines explicit commands, the secrets will not be available to the container to prevent leaking them.
 
-To prevent abusing your secrets from malicious usage, you can limit a secret to a list of images. If enabled they are not available to any other plugin (steps without user-defined commands). If you or an attacker defines explicit commands, the secrets will not be available to the container to prevent leaking them.
+![plugins filter](./secrets-plugins-filter.png)
 
 ## Adding Secrets
 

docs/versioned_docs/version-2.7/20-usage/51-plugins/20-creating-plugins.md

@@ -42,7 +42,7 @@ Values like this are converted to JSON and then passed to your plugin. In the ex
 
 ### Secrets
 
-Secrets should be passed as settings too. Therefore, users should use [`from_secret`](../40-secrets.md#use-secrets-in-settings-and-environment).
+Secrets should be passed as settings too. Therefore, users should use [`from_secret`](../40-secrets.md#use-secrets-in-plugins-via-settings).
 
 ## Plugin library