Bug 1546375 - Requests originating from the API contain no 'userid' attribute in $evm.root
Summary: Requests originating from the API contain no 'userid' attribute in $evm.root
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: API
Version: 5.8.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: GA
: 5.10.0
Assignee: Gregg Tanzillo
QA Contact: Ievgen Zapolskyi
URL:
Whiteboard:
Depends On:
Blocks: 1547527 1565259 1565262
TreeView+ depends on / blocked
 
Reported: 2018-02-16 22:00 UTC by Robb Manes
Modified: 2022-03-13 14:42 UTC (History)
7 users (show)

Fixed In Version: 5.10.0.0
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1547527 1565259 1565262 (view as bug list)
Environment:
Last Closed: 2019-02-11 14:05:11 UTC
Category: ---
Cloudforms Team: ---
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Robb Manes 2018-02-16 22:00:45 UTC
Description of problem:
When any API request is made, for example a retirement request, the $evm.root has no record of the requesting user - there are attributes such as `user` and `user_id` but these are the owner of the object that is being requested upon, not the ID of the reuqester. Additonaly the retirement_initiator is 'system' instead of 'user' as it is when it is initiated from the UI.

When requested from the UI, the $evm.root object contains the `userid` attribute which contains the ID of the requester.  Without this attribute, there is no auditing trail for requests, including retirement.

Primary examples are any action, including `retire` from the `/services` endpoint of the API.

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

How reproducible:
Every time

Steps to Reproduce:
1. Make a request from the API (with or without using auth-tokens) to retire a service
2. Inspect the $evm.root from the event, determine it has no `userid` attribute.

Actual results:
There is no `userid` attribute in $evm.root for requests coming from the API.

Expected results:
There should be similar attributes whether the request is from the UI or the API.

Comment 2 Robb Manes 2018-02-16 22:09:00 UTC
From my inspectiong, seeing as the miq-ae-engine seems to simply consume the userid passed to it, I've set the component as 'API' - please correct me if I'm wrong.

Comment 3 Robb Manes 2018-02-16 22:13:34 UTC
At least the `request_initiator` appears to be resolved in [here][1] - is this possibly a duplicate of bz1487749?

[1]: https://github.com/ManageIQ/manageiq/pull/16179/commits/940e56998c87b6aa8147a6c9062f846d76085e33#diff-d286dd33aa15fb98e02d16598ad92899L14

Comment 4 Greg McCullough 2018-02-19 14:44:31 UTC
Lucy - Please try to validate if this is really a dup on bz1487749.

Comment 5 Sudhir Mallamprabhakara 2018-02-19 15:31:35 UTC
Levgen - This looks like a dupe of BZ1487749. Can you please check.

Thanks
- Sudhir

Comment 10 CFME Bot 2018-02-21 16:20:45 UTC
New commit detected on ManageIQ/manageiq-api/master:
https://github.com/ManageIQ/manageiq-api/commit/8284f6d6bd217f5cdfddbc309c2e7e2131d06398

commit 8284f6d6bd217f5cdfddbc309c2e7e2131d06398
Author:     Jillian Tullo <jtullo>
AuthorDate: Tue Feb 20 13:57:00 2018 -0500
Commit:     Jillian Tullo <jtullo>
CommitDate: Wed Feb 21 08:10:31 2018 -0500

    Set user when queueing VM actions
    
    When VM actions are queued, the user should be set so that it is available as the requester in automate.
    
    Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1546375

 app/controllers/api/vms_controller.rb | 28 +++++++++++++++++++++-------
 spec/requests/vms_spec.rb             | 32 +++++++++++++++++++++++++++++++-
 2 files changed, 52 insertions(+), 8 deletions(-)

Comment 18 Ievgen Zapolskyi 2018-07-03 10:16:35 UTC
Verified in 5.10.0.2


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