Cannot copy from UI into Clipboard Vault 1.16.2

[mughetti]

Describe the bug
After having upgraded Vault from 1.15.6 to 1.16.2 the copy to clipboard feature does not work anymore.
I have both KV secret engine and PKI configured and it fails on both of them.
I have tried also with the root token so I don't think that it is a policy issue
Currently I am accessing Vault through HTTP and I found the issue after having generated a certificate using PKI and failed to copy it and the private key from UI to clipboard
To Reproduce
Steps to reproduce the behavior:

1. Generate a certificate using PKI secret engine (or a secre tin kv engine version 2)
2. Try to use the UI capability to copy it to clipboard
3. A popup with this message "Clipboard copy failed. Make sure the browser clipboard api is allowed"

I tried to add the vault site to have permission to read clipboard in chrome but it did not work

Expected behavior
The UI content copied in the clipboard
Exactly the same configuration worked with Vault 1.15.6

Environment:

• Vault Server Version (retrieve with vault status): 1.16.2
• Vault CLI Version (retrieve with vault version): 1.16.2
• Server Operating System/Architecture: Amazon LInux 2

Vault server configuration file(s):

ui = true
  listener "tcp" {
    address = "0.0.0.0:8200"
    cluster_address = "0.0.0.0:8201"
    tls_disable = true

  }
 storage "raft" {
    path    = "/opt/vault/data/"
    node_id = "%VAULT_ID%"
    retry_join {
      auto_join         = "provider=aws region=%AWS_REGION% tag_key=%TAG_KEY% tag_value=%TAG_VALUE%"
      auto_join_scheme = "http"

   }
  }

  seal "awskms" {
    kms_key_id = "%AUTOUNSEAL_KEY_ID%"
    region     = "%AUTOUNSEAL_KEY_REGION%"
    
  }

  disable_mlock = true
  cluster_addr = "http://%IPADDRESS%:8201"
  api_addr = "http://%IPADDRESS%:8200"

[marcboudreau]

I've tried reproducing this issue but the copying works fine. As you pointed out, by using a root token, it eliminates possible policy issues, which are a common cause for this type of issue. Could you recheck the issue with possibly a different browser or see if you can capture the console logs from your browser when the issue occurs?

[GJSBRT]

I have this issue as well. I assume it is because the clipboard api requires a secure enviroment which is not the case when the vault is running without TLS on a non local setup.

More info about it here:
https://developer.mozilla.org/en-US/docs/Web/API/Clipboard
https://developer.mozilla.org/en-US/docs/Web/Security/Secure_Contexts

The same issue is here as well #26492

[marcboudreau]

Makes sense, I was using HTTP with Chrome. I will re-run the test using Firefox with both HTTP and HTTPS.

[marcboudreau]

I just installed Firefox version 125.0.3 and didn't encounter this issue when using HTTP. I don't doubt that this is indeed the issue, as this is the second time I've seen this reported this week. I'll discuss with the team if there's anything that can be reasonably done to inform the users that Clipboard copying might fail when using HTTP.

[GJSBRT]

Just to make sure you are in a unsecure context. Check to see if window.isSecureContext returns false in your browser's console. When it is returned false, the clipboard api is unavailable.

I have ran vault localy over http and localhost and the clipboard function works as it an secure context. When running on an external/non local ip and over http the clipboard function does not work as it is an unsecure context.

In any case i'd suggest to make it possible to make to copy to clipboard button optional. Currently it is required to get some content. For example when signing an intermediate certificate it is only possible to copy the returned certificates. For now I have to keep developer tools open to get the raw response from the API which is not ideal. If there is a way, then it is not very obvious :).

Update; added/enabled tls on my external vault and now the clipboard function works. Same browser same everything. So I am sure this is the issue.

[mughetti]

Yes , I am currently using HTTP and window.issecureContext returns false. By the way I am going to migrate to HTTPS soon so I expect that this issue will go away
Thank you for the info

[marcboudreau]

Thanks @GJSBRT for the added context.