This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 1472418 - [RFE] Allow user to get user ID in REST API
[RFE] Allow user to get user ID in REST API
Status: NEW
Product: ovirt-engine
Classification: oVirt
Component: RestAPI (Show other bugs)
Unspecified Unspecified
low Severity medium (vote)
: ovirt-4.2.0
: ---
Assigned To: Ori Liel
samuel macko
: FutureFeature
Depends On:
  Show dependency treegraph
Reported: 2017-07-18 12:43 EDT by jniederm
Modified: 2017-10-16 08:09 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: Infra
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
mperina: ovirt‑4.2?
pstehlik: testing_plan_complete-
rule-engine: planning_ack?
mperina: devel_ack+
pstehlik: testing_ack+

Attachments (Terms of Use)

  None (edit)
Description jniederm 2017-07-18 12:43:58 EDT
It would be nice to allow REST API users to get their user ID. It can come handy for example when managing own ssh public keys (

It may be represented for example like a link

GET /api

<link href="/api/users/{currentUserId}" rel="currentUser" />

or magic user id

GET /api/users/me
Comment 1 Juan Hernández 2017-07-18 12:55:41 EDT
This makes sense to me, as it has been requested already more than once. I'd suggest to implement it as an attribute inside the 'Api' type:

  GET /ovirt-engine/api

    <authenticated_user href="/ovirt-engine/api/users/123"/>

Note that we will probably want to support user impersonation in the future. This should be clearly documented as the user that was authenticated. If/when we implement impersonation, then we can add another link:

    <authenticated_user href="/ovirt-engine/api/users/123"/>
    <effective_user href="/ovirt-engine/api/users/456"/>

In this potential future scenario the actual permissions in effect will be those of user 456, not of user 123, so it may be better to add both attributes from the very beginning, even if they will initially have the same value.
Comment 2 Juan Hernández 2017-07-18 12:57:34 EDT
Jakub, can you elaborate a bit on what is the use case for this? I mean, why it is needed or convenient. That would help when deciding if/when this should be implemented.
Comment 3 jniederm 2017-07-18 13:48:15 EDT
Sure. We come across the issue of (not) having a user ID while trying to implement public ssh keys management in web-ui project (a userportal replacement, The id is necessary to manage any resources linked from user entity: sshpublickeys, permissions, tags, roles. According to documentation ( it's also domain and groups.

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