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.
according to https://github.com/oVirt/ovirt-web-ui/issues/509 bug already fixed.
okey, apparently not fixed - if you have a UserRole and not a UserVmManager than the issue still persists.
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>
Ondro, you seem to be the last one rewriting that method. What do you think?
(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.
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
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.