You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Often, a user accesses the cve.org search box when seeking information about a vulnerability that was recently disclosed on a CNA's web site, but does not yet have a published CVE Record stored in the OpenSearch cluster. For example, the product supplier CNA publishes vulnerability details on its own website at 9 AM, sends email about this to all customers at 9:05 AM, and publishes the CVE Record at 9:10 AM. Then, the CVE Record is stored in the OpenSearch cluster at possibly 9:30 AM or 9:40 AM.
The user enters unique and specific keywords in the search box at 9:06 AM, presses the Search button, and then keeps pressing the Search button again, e.g., once every 10 minutes for the next few hours. The user observes that the search results never include the recently published CVE Record. However. if the user makes a new visit to the cve.org website after 9:40 AM, and enters exactly those same keywords. then the search results do include that recently published CVE Record.
For many users, this behavior is counterintuitive and interferes with their ability to find CVE Record information as quickly as possible.
As far as I can tell, re-pressing the Search button can only retrieve new results if the Vue reactive data, such as the .query value, has changed. For example, possibly a Search button click (without any change in the entered keywords) does not always directly result in a getSearchResults() call or other re-fetch, and does not cause watcher code to be executed again.
There is perhaps a workaround if the user, who is actually interested in keywords K1 and K2, switches temporarily to keyword T1 and presses the Search button, and then goes back to keywords K1 and K2 and presses the Search button. This will, as far as I know, retrieve the latest available search results. However, many users would not realize that this workaround is needed, and it may be challenging to document this as a good solution.
The text was updated successfully, but these errors were encountered:
Often, a user accesses the cve.org search box when seeking information about a vulnerability that was recently disclosed on a CNA's web site, but does not yet have a published CVE Record stored in the OpenSearch cluster. For example, the product supplier CNA publishes vulnerability details on its own website at 9 AM, sends email about this to all customers at 9:05 AM, and publishes the CVE Record at 9:10 AM. Then, the CVE Record is stored in the OpenSearch cluster at possibly 9:30 AM or 9:40 AM.
The user enters unique and specific keywords in the search box at 9:06 AM, presses the Search button, and then keeps pressing the Search button again, e.g., once every 10 minutes for the next few hours. The user observes that the search results never include the recently published CVE Record. However. if the user makes a new visit to the cve.org website after 9:40 AM, and enters exactly those same keywords. then the search results do include that recently published CVE Record.
For many users, this behavior is counterintuitive and interferes with their ability to find CVE Record information as quickly as possible.
As far as I can tell, re-pressing the Search button can only retrieve new results if the Vue reactive data, such as the .query value, has changed. For example, possibly a Search button click (without any change in the entered keywords) does not always directly result in a getSearchResults() call or other re-fetch, and does not cause watcher code to be executed again.
There is perhaps a workaround if the user, who is actually interested in keywords K1 and K2, switches temporarily to keyword T1 and presses the Search button, and then goes back to keywords K1 and K2 and presses the Search button. This will, as far as I know, retrieve the latest available search results. However, many users would not realize that this workaround is needed, and it may be challenging to document this as a good solution.
The text was updated successfully, but these errors were encountered: