Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be available on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 1568669 - 404 response when query for VM's sessions if a session already opened with a user account
Summary: 404 response when query for VM's sessions if a session already opened with a ...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: RestAPI
Version: 4.3.0
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ovirt-4.2.4
: ---
Assignee: Ori Liel
QA Contact: Lucie Leistnerova
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-04-18 04:09 UTC by Scott Dickerson
Modified: 2018-06-26 08:40 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
The bug happens when getting user information to set within the session object. This is wrong to begin with, because the convention in the API is to return the data of the entity which is being retrieved, and only links to referenced entities, not their contents. So the fix to this bug will result in only the link to the user set within the session, and this should obviously work for both admin and non-admin users.
Clone Of:
Environment:
Last Closed: 2018-06-26 08:40:39 UTC
oVirt Team: Infra
rule-engine: ovirt-4.2+


Attachments (Terms of Use)
reproduce.sh -- demonstrate the 404 error (1.00 KB, application/x-shellscript)
2018-04-18 04:09 UTC, Scott Dickerson
no flags Details


Links
System ID Private Priority Status Summary Last Updated
oVirt gerrit 91525 0 master MERGED restapi: 404 for GET vm sessions 2018-05-23 11:58:48 UTC
oVirt gerrit 91539 0 ovirt-engine-4.2 MERGED restapi: 404 for GET vm sessions 2018-05-23 15:47:28 UTC

Description Scott Dickerson 2018-04-18 04:09:56 UTC
Created attachment 1423319 [details]
reproduce.sh  -- demonstrate the 404 error

Description of problem: From the ovirt-web-ui project, a VM's console sessions are queried prior to opening a new session so a "console is in use" message can be presented prior to opening the console.  Specifically this error is coming from the REST API calls in a particular order.  If a console session is created (by asking REST for a "applcation/x-virt-viewer" config of a particular graphics console) by a USER account, the next VM session request by a USER account will always fail with a 404 response.

Version-Release number of selected component (if applicable): Tested against master, but I believe it is older.

How reproducible: Every time.  Can be replicated by a series of CURL calls.

Steps To Reproduce: See attached script.

Actual results: The __sessions__ request by a user account returns a 404.

Expected results: The __sessions__ request by a user account to return a valid document just like the request by an admin account does.

Additional info: The only way to clear the 404 error is to open the VM's console with an admin account. 

The only difference is that when __graphicsconsoles__ is called by a user, the Filter header is set to true.  When it is called by an admin, the Filter header is set false. My understanding is this is the correct way to use the Filter header.

Comment 1 Tomas Jelinek 2018-04-20 11:36:17 UTC
according to https://github.com/oVirt/ovirt-web-ui/issues/509 bug already fixed.

Comment 2 Tomas Jelinek 2018-04-26 09:27:30 UTC
okey, apparently not fixed - if you have a UserRole and not a UserVmManager than the issue still persists.

Comment 3 Tomas Jelinek 2018-05-03 07:47:07 UTC
The issue is in BackendVmSessionsResource.setSessionUser(). What happens is this:
- have a VM which has a console which is not occupied
- click the console button on frontend
- it checks if there is some active session first. Since there is none, it will not end in setSessionUser() method so it will no crash
- than, if you do it again, there will be an active session so it will end up in the setSessionUser()
- this method than uses a hack in order to fill the hrefs to user into the resulting session object - it calls the API method to get the user (e.g. equivalent to GET /users/<id>) to re-use the hrefs already filled in there. But, if you do this as a regular user, you will get all the users (including yourself) filtered out and the method fails resulting in 404. The correct solution should be to create the links using LinkHelper or something similar and not using the GET /users/<id>

Comment 4 Michal Skrivanek 2018-05-03 08:03:38 UTC
Ondro, you seem to be the last one rewriting that method. What do you think?

Comment 5 Ondra Machacek 2018-05-07 12:15:26 UTC
(In reply to Michal Skrivanek from comment #4)
> Ondro, you seem to be the last one rewriting that method. What do you think?

I agree. Actually, I think the user should access his ID at /user/{id}. So it 
should work as currently is, but we don't allow it. The user can access 
/user/{admin_internal_id}, which is weird.

Comment 6 Lucie Leistnerova 2018-06-07 10:48:51 UTC
Sessions returned after unsuccessful console run for user with only UserRole, also with UserVmManager.

verified in ovirt-engine-restapi-4.2.4.1-0.1.el7.noarch

Comment 7 Sandro Bonazzola 2018-06-26 08:40:39 UTC
This bugzilla is included in oVirt 4.2.4 release, published on June 26th 2018.

Since the problem described in this bug report should be
resolved in oVirt 4.2.4 release, it has been closed with a resolution of CURRENT RELEASE.

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


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