Using REST API to move user to different OU

UCS - Univention Corporate Server
#1

I am trying to use the UCS REST API to move an existing user from one OU to another.

For testing, I am using this cURL command:
curl -X PUT -H "Accept: application/json" -H "Content-Type: application/json" -H 'If-Match: "4ec61010c15aef4d59e3746aa6bdfb531f88b9e9"' 'https://user:password@ucs-server.org/univention/udm/users/user/uid%3Dusername%2Cou%3DSOURCE%2Cou%3Dtwo%2Cou%3Dthree%2Cdc%3Dcity%2Cdc%3Dorg%2Cdc%3Dde' --data @mydata.json

and mydata.json contains the following text:

{
    "dn": "uid=username,ou=source,ou=two,ou=three,dc=city,dc=org,dc=de",
    "position": "ou=target,ou=three,dc=city,dc=org,dc=de",
    "properties": {
    }
}

The “dn” describes the user as it is now, and “position” is adjusted to reflect the new location where the user should be moved to.

Unfortunately, this does not work (user is not moved) and this is what I get as response:
{"finished": false, "errors": false, "_links": {"curies": [{"href": "https://ucs-server.org/univention/udm/relation/{rel}", "name": "udm", "templated": true}]}, "id": "42465069-d8b6-4315-81a4-f42d91d47ffc"}

So…

First question: what is it this response is trying to tell me?

And second question: How do I move a user instead?

Thanks!

#2

your request ist correct. You are getting a HTTP 202 Accepted response. As moving objects may take longer than e.g. HTTP request timeouts this is an asynchronous operation. The response contains a Location header with a temporary URL which tells you the status. This again gives you a 3XX redirection to the same URL with a Retry-After header which specifies the time to wait between following the redirect. If the operation is finished on server side you are getting a redirection to the moved object in the new location.

#3

Thanks very much for the speedy reply! Good to know I am not doing something completely stupid (yet). :slight_smile:

I am not very experienced with REST APIs and mean no offense, but three requests with incremental header data just to do a simple ldapmodify with changetype: modrdn seems rather excessive. Why does moving to an OU take so much longer that it warrants such a complicated staging?

Isn’t there a more direct way to move a user to a different OU?

#4

no, there is currently no more efficient way. This is because we currently don’t differentiate what kind of object is moved. Moving a whole OU or CN is more than just a modrdn as it moves also all sub-objects. If there are 1000 objects underneath we would run into timeout problems.

#5

I created a bug report for that: Bug 55019 – [UDM REST API] enhance moving of objects without subordinates

1 Like
#6

Moving entire OUs being slow and timing out → yes, that makes a lot more sense to me now, thank you for the clarification!

And thank you for creating the report to improve this. I wholeheartedly agree that moving an individual user could be more streamlined. After all, how often do you need to automate moving entire OUs in daily work? :wink:

(I just tried to add myself to the bug report by creating a new account but did not receive any email…)

#7

Hi @Best

now that I had some more time to look more into this I need to come back to you, as the response I am getting is 201 (created), not 202 (accepted).

I was hoping that setting the PHP curl options to $options[CURLOPT_FOLLOWLOCATION] = true; would solve my issues, but apparently this will only work for 3xx response codes…

This is the full header of the reply:

Request Header: HTTP/1.1 201 Created
Date: Mon, 01 Aug 2022 14:18:24 GMT
Server: Univention/1.0
X-Permitted-Cross-Domain-Policies: master-only
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
Content-Security-Policy: frame-ancestors 'none';
Content-Length: 219
Content-Language: en-US
Vary: Accept,Accept-Language,Accept-Encoding,Authorization
Last-Modified: Mon, 01 Aug 2022 14:17:31 GMT
Etag: "62c321baff0e3188091712c6818184c0ff1d3d49"
Location: https://ucs-server.org/univention/udm/progress/312cda02-f051-4313-a30a-bc7623095eaa
Cache-Control: private, must-revalidate
Link-Template: <https://ucs-server.org/univention/udm/relation/{rel}>; rel="curies"; name="udm"
Content-Type: application/json
Via: 1.1 ucs-server.org

Shouldn’t a 201 indicate that the request was successful and a resource was created?

Thanks again!

1 Like
#8

You are right: our return status is wrong and should be 202 on a move operation.
https://forge.univention.org/bugzilla/show_bug.cgi?id=55057

#9

That was quick, thanks!
But shouldn’t this be 3xx anyway, to make sure the redirection works automatically (e.g. in PHP and Python)?

#10

it’s not a redirection but an async operation which is started. The tools/libraries should learn to also provide functionality to follow redirects from 201 and 202 Location headers.

Mastodon