Bug 2006067 - Objects are not valid as a React child
Summary: Objects are not valid as a React child
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Management Console
Version: 4.7
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: 4.11.0
Assignee: Yadan Pei
QA Contact: Yadan Pei
URL:
Whiteboard:
Depends On:
Blocks: 2028292 2053703
TreeView+ depends on / blocked
 
Reported: 2021-09-20 19:45 UTC by Nick Curry
Modified: 2022-08-10 10:37 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Cause: We were not correctly handling permissions when approving InstallPlans or correctly handling error messages in the UI. Consequence: Users could hit an unhandled error. Fix: Updated code to process error messages correctly and show them in the UI. Altered the way we use permissions so it was consistent. Added warning messages and hid the interactive buttons if users do not have the correct permissions. Result: Bug is fixed.
Clone Of:
Environment:
Last Closed: 2022-08-10 10:37:25 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
Witnessed a bug on 4.7 (250.45 KB, image/png)
2021-11-02 17:21 UTC, ralpert
no flags Details
empty username in alert message (424.07 KB, image/png)
2021-12-27 03:25 UTC, Yadan Pei
no flags Details
username shown in alert message (255.83 KB, image/png)
2022-02-11 09:55 UTC, Yadan Pei
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Github openshift console pull 10387 0 None open [WIP] Bug 2006067: Fix OLM error handling 2021-11-02 20:56:32 UTC
Github openshift console pull 10782 0 None open Bug 2006067: Handle blank usernames in error message 2022-01-05 19:45:31 UTC
Red Hat Product Errata RHSA-2022:5069 0 None None None 2022-08-10 10:37:45 UTC

Description Nick Curry 2021-09-20 19:45:18 UTC
Description of problem:

Users being shown React error when trying to perform action in OpenShift UI


Version-Release number of selected component (if applicable):

4.7.22

How reproducible:

100%


Steps to Reproduce:
1. Create a role without the ability to "update" InstallPlans, but with the other verbs like get and patch.
2. Try to approve an installplan in the UI

Actual results:

Objects are not valid as a React child (found: Error: installplans.operators.coreos.com "install-sgxdf" is forbidden: User "w77378" cannot update resource "installplans" in API group "operators.coreos.com" in the namespace "developer-monitoring"). If you meant to render a collection of children, use an array instead.


Expected results:

OpenShift UI handles error and displays message in the UI.


Additional info:

Comment 1 ralpert 2021-11-02 15:34:31 UTC
I haven't been able to recreate this using our latest 4.10 code. I spoke to the team and it sounds like we are not backporting many fixes to 4.7 at this time. Since it is in maintenance support, only critical and selected high priority fixes are being delivered to 4.7. I'm going to do a little more investigation in what earlier clusters I am able to obtain builds for to confirm that this is indeed fixed in a later version before I close it out.

To test this in 4.10, I created a new cluster role based on the "edit" role YAML. I removed "update" on installplans and added "patch" for installplans. I was able to approve installplans with no errors in the UI.

Comment 2 ralpert 2021-11-02 15:44:46 UTC
Spoke to Jakub and determined that this should be treated as a medium severity bug since we are not properly handling and displaying errors.

Comment 3 ralpert 2021-11-02 17:21:13 UTC
Created attachment 1839291 [details]
Witnessed a bug on 4.7

I was able to recreate a missing error bug on 4.7, but it's not clear if this is the same bug reported.

Comment 4 ralpert 2021-11-02 17:24:29 UTC
Created attachment 1839292 [details]
Able to recreate on 4.7

Comment 5 ralpert 2021-11-02 17:25:50 UTC
I was able to recreate the bug on 4.7. I am currently working on obtaining a 4.8 cluster so I can investigate if the bug was fixed in 4.8. It appears to have been fixed by 4.10 at least.

Comment 6 ralpert 2021-11-02 18:06:57 UTC
Able to recreate in 4.8. Will try 4.9 next, and if present on 4.9, will try to recreate again on 4.10 to confirm whether a fix is present or not.

Comment 7 ralpert 2021-11-02 19:13:23 UTC
Recreated on 4.9 with cluster-bot. Trying again on a shared 4.10 cluster to see whether the bug is present or not. If I am able to recreate on 4.10 today, then we should be able to fix this in a later release, though probably not in 4.7.

Comment 8 ralpert 2021-11-02 20:52:51 UTC
Alright, got it! 

I have a preliminary fix for 4.10. I just need to get a design question answered by our design team for the InstallPlan page error handling - it seems off as it is right now. I'll also work on figuring out how far we can backport this past 4.10.

Comment 11 Yadan Pei 2021-12-27 03:24:37 UTC
1. cluster admin user subscribe prometheus operator into namespace 'yapei' with 'Manual' approval method
2. Create a ClusterRole with following YAML
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: yapei-read-csvipsub
rules:
  - verbs:
      - get
      - list
      - watch
    apiGroups:
      - operators.coreos.com
    resources:
      - installplans
  - verbs:
      - get
      - list
      - watch
    apiGroups:
      - operators.coreos.com
    resources:
      - subscriptions
  - verbs:
      - get
      - list
      - watch
    apiGroups:
      - operators.coreos.com
    resources:
      - clusterserviceversions
  - verbs:
      - get
      - list
      - watch
    apiGroups:
      - operators.coreos.com
    resources:
      - catalogsources
3. Create a ClusterRoleBinding and grant ^^ clusterrole to normal user 'yapei1'
$ oc describe ClusterRoleBinding yapei-test-rb
Name:         yapei-test-rb
Labels:       <none>
Annotations:  <none>
Role:
  Kind:  ClusterRole
  Name:  yapei-read-csvipsub
Subjects:
  Kind  Name    Namespace
  ----  ----    ---------
  User  yapei1  


4. User 'yapei1' logins to console and navigate to Operators -> Installed Operators page, click on the operator which is pending on approval.
Click 'Upgrade available' or `1 requires approval` button on Subscription details page

We can see message
"""
Missing sufficient privileges for manual InstallPlan approval
User "" does not have permissions to patch resource InstallPlans in API group "operators.coreos.com" in the namespace "yapei."
"""

It looks like we didn't get correct user name because the username is empty in the alert message

this is checked against 4.10.0-0.nightly-2021-12-23-153012, assign back for investigation

Comment 12 Yadan Pei 2021-12-27 03:25:38 UTC
Created attachment 1847885 [details]
empty username in alert message

Comment 13 ralpert 2022-01-05 19:46:01 UTC
Good catch; thank you Yadan! :)

I'm fixing it here if you wouldn't mind taking a look at that: https://github.com/openshift/console/pull/10782

Comment 17 Yadan Pei 2022-02-11 09:55:33 UTC
Created attachment 1860560 [details]
username shown in alert message

follow the same steps in comment 11, now the alert message shows username correctly!


Missing sufficient privileges for manual InstallPlan approval
User "yapei" does not have permissions to patch resource InstallPlans in API group "operators.coreos.com" in the namespace "yapei-project-1."


verified on 4.11.0-0.nightly-2022-02-10-180317

Comment 19 errata-xmlrpc 2022-08-10 10:37:25 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Important: OpenShift Container Platform 4.11.0 bug fix and security update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2022:5069


Note You need to log in before you can comment on or make changes to this bug.