Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

JSON view does not update content on version change #25029

Closed
somerandow opened this issue Jan 24, 2024 · 1 comment · Fixed by #25152
Closed

JSON view does not update content on version change #25029

somerandow opened this issue Jan 24, 2024 · 1 comment · Fixed by #25152
Labels

Comments

@somerandow
Copy link

Describe the bug

In 1.15.4, when viewing a secret in the the read-only JSON view, the drop-down menu to select a different version of the secret does not reload or update the content of the JSON view. This appears to occur for both complex and non-complex kv secrets.

For example, version 2 of a secret, using the JSON view:
Screenshot 2024-01-24 at 8 36 27 AM

then selecting version 1 from the drop-down, the version number and creation time change, but the content does not:
Screenshot 2024-01-24 at 8 36 34 AM

However, when viewing the secret in the "default" view, the content does change. Version 2:

Screenshot 2024-01-24 at 8 39 25 AM

and then version 1:

Screenshot 2024-01-24 at 8 39 32 AM

I believe this may be related to #24290, as I can confirm what I believe to be the correct behavior works in 1.15.2.

To Reproduce
Steps to reproduce the behavior:

  1. Create a new kv secret, using default or JSON editor
  2. Create a second version of the secret with different contents
  3. Toggle the JSON view on
  4. Switch back and forth between versions using the drop-down, secret contents do not change
  5. Toggle JSON view off
  6. Switch back and forth between versions using drop-down, secret contents do change

Expected behavior
The JSON view should update its contents to reflect the content of the version of the secret currently selected.

This expected behavior is consistent with what I'm able to test in Vault 1.15.2. Willing to provide screenshots of expected behavior if needed.

Environment:

  • Vault Server Version (retrieve with vault status): 1.15.4
  • Vault CLI Version (retrieve with vault version): N/A
  • Server Operating System/Architecture: OpenShift (Kubernetes 1.25.12)

Vault server configuration file(s):

disable_mlock = true
ui = true
cluster_name = "XXXXXX"
listener "tcp" {
  tls_disable = 0
  address = "[::]:8200"
  cluster_address = "[::]:8201"
  http_read_timeout = "600s"
  tls_cert_file = "/tls/tls.crt"
  tls_key_file = "/tls/tls.key"
  telemetry {
    unauthenticated_metrics_access = "true"
  }
}
storage "raft" {
  path = "/vault/data"
  performance_multiplier = 1
  autopilot_reconcile_interval = "5s"
  autopilot_update_interval = "1s"
  retry_join {
    leader_tls_servername = "XXXX"
    leader_ca_cert_file = "/tls/ca.crt"
    auto_join = "provider=k8s namespace=XXX"
  }
autopilot {
    cleanup_dead_servers = "true"
    last_contact_threshold = "10s"
    dead_server_last_contact_threshold = "1h"
    max_trailing_logs = 1000
    min_quorum = 3
    server_stabilization_time = "10s"
  }
}
service_registration "kubernetes" {}
seal "gcpckms" {XXXXXXX}
telemetry {
  prometheus_retention_time = "120s",
  disable_hostname = true
}

Additional context

As a workaround, selecting the version from the drop-down, and then reloading the page does force the content to update, but it's not made clear to end-users that this workaround exists.

@Monkeychip Monkeychip added the ui label Jan 30, 2024
@Monkeychip
Copy link
Contributor

Monkeychip commented Jan 31, 2024

@somerandow thank you for reporting this issue. I have been able to replicate and can confirm this is indeed a bug. I'll report back when a fix is in the works and what release it will be targeted towards 1.15.6 and 1.16.0 should have this fix in them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants