Support Migration Notice: To update migrated JIRA cases click here to open a new case use www.vmware.com/go/sr | vFabric Hyperic 5.7.0 is Now Available

Hyperic HQ

Fixing alerts in batch with the "Fix all previous alerts" option causes 403 Forbidden error

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Critical Critical
  • Resolution: Fixed
  • Affects Version/s: 4.5.2, 4.6
  • Fix Version/s: 4.5.2.1, 4.6, 4.x Sprint 27
  • Component/s: None
  • Case Links:
    none
  • Regression:
    Yes
  • Story Points:
    3
  • Tags:

Description

When selecting all alerts in the alerts center and fixing the alerts in batch with the "Fix all previous alerts" option, the Alert Center dialog displays a "An error occurred processing your request." error. An inspection of the JSON response reveals:

An error occurred processing your request. Error: Unable to load /alerts/RemoveAlerts.do?org.apache.catalina.filters.CSRF_NONCE=CE764D4EBDC111884A2EF8CB89AFFDE5 status:403

This appears to be a CSRF regression bug. This would happen anywhere in Hyperic where alerts are fixed in batch with the "Fix all previous alerts" option, such as the Alerts Center, Ops Center, and Recent Alerts dashboard portlet. This does not impact the resource alert page because it does not fix alerts in json batch mode.

Activity

Hide
Patrick Nguyen added a comment -

FIX: Get new CSRF token for subsequent POST requests when fixing alerts in batch

Show
Patrick Nguyen added a comment - FIX: Get new CSRF token for subsequent POST requests when fixing alerts in batch
Hide
Patrick Nguyen added a comment -

To see this 403 error, need to select more than 10 alerts to fix with the "Fix all previous alerts" option checked.

Show
Patrick Nguyen added a comment - To see this 403 error, need to select more than 10 alerts to fix with the "Fix all previous alerts" option checked.
Hide
Ryan Morgan added a comment -

Nipuna,

I'm going to re-open this and mark 4.5.2.1 fix version. Please do the same on any future CSRF bugs that exist in 4.5.2, we can't have regressions like this on our maintenance line.

Show
Ryan Morgan added a comment - Nipuna, I'm going to re-open this and mark 4.5.2.1 fix version. Please do the same on any future CSRF bugs that exist in 4.5.2, we can't have regressions like this on our maintenance line.
Hide
Ryan Morgan added a comment -

Mark fix for 4.5.2.1 (4.5.2.x branch)

Show
Ryan Morgan added a comment - Mark fix for 4.5.2.1 (4.5.2.x branch)
Hide
Patrick Nguyen added a comment -

Just discovered another use case where this 403 error happens:

1) from the Alert Center (or Ops Center or Recent Alerts dashboard portlet), individually select a single alert and fix it (any option ("Fix All" or not) will do).
2) Repeat 10 more times so that more than 10 POST requests are made to fix alerts.

After the 10th POST request with the same CSRF token, the 403 error occurs.

Show
Patrick Nguyen added a comment - Just discovered another use case where this 403 error happens: 1) from the Alert Center (or Ops Center or Recent Alerts dashboard portlet), individually select a single alert and fix it (any option ("Fix All" or not) will do). 2) Repeat 10 more times so that more than 10 POST requests are made to fix alerts. After the 10th POST request with the same CSRF token, the 403 error occurs.
Hide
Patrick Nguyen added a comment -

FIX 2: Get new CSRF token for subsequent POST requests when fixing/acking individual alerts

Show
Patrick Nguyen added a comment - FIX 2: Get new CSRF token for subsequent POST requests when fixing/acking individual alerts
Hide
Patrick Nguyen added a comment -

FIX 3: Get new CSRF token for subsequent POST requests when acking individual alerts by clicking the ack icon

Show
Patrick Nguyen added a comment - FIX 3: Get new CSRF token for subsequent POST requests when acking individual alerts by clicking the ack icon

People

Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved:
    Last comment:
    2 years, 39 weeks, 5 days ago