issues of updating user via keystone rest api
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Identity (keystone) |
Fix Released
|
Medium
|
Ya Hong Du |
Bug Description
We found two problems related to updating user via keystone.
(1) Via, the instruction of updating user on, http://
It is required POST action to update the existing user email, name, or description.
Via my verification, POST to update existing user caused
{
"error": {
"message": "The resource could not be found.",
"code": 404,
"title": "Not Found"
}
}
The detailed for this test is,
[root@lijunj ~]# curl -i http://
> {
> "user": {
> "id": "fee07a4ebc0147
> "description": "v3 keystone user test",
> "email": "none@",
> "enabled": true
> }
> }'
HTTP/1.1 404 Not Found
Vary: X-Auth-Token
Content-Type: application/json
Content-Length: 93
Date: Mon, 15 Jul 2013 02:23:44 GMT
{"error": {"message": "The resource could not be found.", "code": 404, "title": "Not Found"}}
I ensure the id fee07a4ebc01474
--List user
[root@lijunj ~]# curl -i http://
HTTP/1.1 200 OK
Vary: X-Auth-Token
Content-Type: application/json
Content-Length: 349
Date: Mon, 15 Jul 2013 02:24:51 GMT
{"user": {"aa": "144442", "name": "test", "bb": "23", "debug-
The user fee07a4ebc01474
We may discuss this document correction-ability. And, POST can not be used for updating user, but PUT action can.
(2) Document in http://
--Create user
curl -i http://
{
"user": {
"name": "li-03",
"email": "none@",
"tenantId": "ccaf7621482a41
"password": "passw0rd",
"enabled": true
}
}'
Response:
{"user": {"description": "v2.0 keystone user test", "name": "li-03", "enabled": true, "email": "none@", "id": "00027b03821f4b
-- List the tenant users.
curl -i http://
{"users": [{"name": "sceagent", "id": "07d544b772ce4a
....//The content is not important. li-03 is in tenant ccaf7621482a41c
{"name": "li-03", "description": "v2.0 keystone user test", "enabled": true, "email": "none@", "id": "00027b03821f4b
--Update user. Used anther tenant id inside, and rest api does not throw exception.
curl -i http://
{
"user": {
"name": "li-03",
"email": "none@",
"tenantId": "e0cdb35aa15d45
"password": "passw0rd",
"enabled": true
}
}'
Response:
{"user": {"description": "v2.0 keystone user test 01", "name": "li-03", "extra": {"tenantId": "e0cdb35aa15d45
--List tenant e0cdb35aa15d45f
curl -i http://
Response:
{"users": []}
The user was not updated to add into e0cdb35aa15d45f
From above, we can not upate user to change a existing user tenant/project. Is it good way we add the tight 'assert'/judgement for any attemption of updating user tenantId property?
Changed in linux (Ubuntu): | |
status: | New → Incomplete |
affects: | linux (Ubuntu) → keystone |
Changed in keystone: | |
status: | New → Triaged |
tags: | added: update |
Changed in keystone: | |
status: | Triaged → Confirmed |
Changed in keystone: | |
assignee: | nobody → Dazhao Yu (dzyu) |
Changed in keystone: | |
assignee: | Dazhao Yu (dzyu) → Ya Hong Du (yahongdu) |
Changed in keystone: | |
importance: | Low → Medium |
Changed in keystone: | |
assignee: | Ya Hong Du (yahongdu) → Morgan Fainberg (mdrnstm) |
Changed in keystone: | |
assignee: | Morgan Fainberg (mdrnstm) → Ya Hong Du (yahongdu) |
Changed in keystone: | |
assignee: | Ya Hong Du (yahongdu) → Morgan Fainberg (mdrnstm) |
Changed in keystone: | |
assignee: | Morgan Fainberg (mdrnstm) → Ya Hong Du (yahongdu) |
Changed in keystone: | |
assignee: | Ya Hong Du (yahongdu) → Morgan Fainberg (mdrnstm) |
Changed in keystone: | |
assignee: | Morgan Fainberg (mdrnstm) → Ya Hong Du (yahongdu) |
Changed in keystone: | |
assignee: | Ya Hong Du (yahongdu) → Dolph Mathews (dolph) |
Changed in keystone: | |
assignee: | Dolph Mathews (dolph) → Ya Hong Du (yahongdu) |
Changed in keystone: | |
milestone: | none → havana-rc1 |
status: | Fix Committed → Fix Released |
Changed in keystone: | |
milestone: | havana-rc1 → 2013.2 |
I'm wondering if this is a recent doc bug? Need to research git history before attempting a "fix" in the implementation. Filing as low in keystone because this API is deprecated in favor of v3 anyway.