Tips: Dynamically Creating Users in the DFC

Earlier today, James McGovern asked how to create a user through code in Documentum using either the DFC or DFS. I responded to him directly as I didn’t want him to have to wait for me to write a blog post to get the answer. However, I decided to share my answer with everyone while I watch the big game.

Creating a User in the DFC

Starting in version 5.3, Documentum’s Content Server allowed for users to exist that had no external authentication. This is a beautiful feature that allows for the creation of test accounts and accounts for external users that do not need accounts inside the network. Before this, we either had to create local accounts that had no rights on the server, or create a custom authentication plug-in that would handle the situation specifically.

Here is the code. I tested it myself on 5.3 sp5 today. [Edit: Note, this only shows the steps outside without the benefit of the context from a full implementation.]

IDfUser dfcUser = (IDfUser) dfcSession.newObject("dm_user");
dfcUser.setUserName("Dave User");
dfcUser.setUserLoginName("daveuser");
dfcUser.setString("user_source","inline password");
dfcUser.setString("user_password","Pa55w0rd");
dfcUser.setDefaultFolder("/Users/Dave User",true);
//This next line I added during the game and didn't test
dfcUser.setClientCapability(DF_CAPABILITY_CONTRIBUTOR);
dfcUser.save();

This code snippet assumes the following:

  • That dfcSession is a valid, existing session.
  • The user authenticated in dfcSession is either a System Administrator or Super User.
  • This code is used in 5.3 sp2 or higher. Why? There was a bug that didn’t encrypt the password upon the save. This meant that when a user tried to use the password, they didn’t match. The DFC now encrypts the password upon save.
  • That you have this in a well structured Java application or procedure to handle errors and problems (like what if the user already exists?). [Added 2008-01-09]

Always set the Client Capability. Never let the default rule the roost. This includes the other values that I haven’t set like default ACL and Group. This lets people looking at the code know if a setting in the system was an oversight or from a conscious decision.

I could just as easily created a DQL statement that creates the user and executed it as well. Also need 5.3 sp2 for the inline password to be properly encrypted.

Deleting a User in the DFC

I actually forgot to sent this one to James earlier. However, this is a little easier and hopefully his friend was smart enough to deduce it from the code above. [Edit: As mentioned below, deleting users should not be done casually.]

String sQualification = "dm_user where user_name ='Dave User'";
IDfUser dfcUser = (IDfUser) dfcSession.getObjectByQualification(sQualification);
dfcUser.destroy();

Didn’t test this, but if it doesn’t work, someone please tell me and I’ll fix it.

9 thoughts on “Tips: Dynamically Creating Users in the DFC

  1. Chris Campbell says:

    When deleting a user, you always need to think all the way through the reason behind it. For integrity purposes, and especially in a production environment, it’s always better to set the user as inactive rather than deleting the user. Don’t forget that just about every object in the repository has an owner, and the system tends to pitch a fit if it can’t find the owner listed.

    Like

  2. Chris, damn straight! I rushed into answering the question without throwing-out the usual caveats. In addition to the owner, you lose a lot of history when you delete an item.

    If you absolutely must delete a user, make sure that they don’t own any ACLs or other objects. You can re-assign them as well to other users, or a static “defunct” user that is more of a placeholder. OR you can simply mark them as inactive which is what I tend to do and what I setup my LDAP jobs to do.

    Like

  3. Sagi says:

    Regarding Creating a User in the DFC…?
    How i can get the password of any inline user using dfc?
    Thanks in Advance

    Like

  4. Sagi, I don’t think you can and I am pretty sure I don’t want that capability as it can lead to security holes. Try dfcUser.getString(”user_password”); and it should hopefully fail.

    Like

Comments are closed.