It's all about the answers!

Ask a question

How can I add a user to the administrators list for a CLM project using API and CURL?

Ryan McBryde (5511130) | asked Oct 08 '21, 5:24 p.m.

I am trying to add my id to the "admins" list for a project, by including a "X-Jazz-CSRF-Prevent" with the JSESSIONID and passing my userid info as an xml string to a POST command.  I am getting a "Cannot save the Project Area" error even though the id that I am running the script with is a member of the JazzAdmins group and I can easily go in and add my userid to the Admins list using the GUI.  I am also sometimes seeing a "403 Forbidden" response.

I am using -ssl as an argument and I think my servers all use TLSv1.2.  

Would that make a difference?  

Any thoughts would be appreciated.  


3 answers

permanent link
Ralph Schoon (62.7k33643) | answered Oct 09 '21, 4:45 a.m.

POST is usually associated with CREATE. Try PUT instead.

Ralph Schoon commented Oct 09 '21, 4:48 a.m. | edited Oct 09 '21, 5:30 a.m.
Note, in my experience it is more efficient to use POSTMAN or RESTCLIENT and get the cURL commands as an export.
Also note, if you have API questions provide details on what API, ideally enough that someone could reproduce. EWM has multiple HTTP based APIs

permanent link
Ian Barnard (1.8k613) | answered Oct 11 '21, 5:13 a.m.
edited Oct 11 '21, 5:50 a.m.
Sounds like you aren't properly authenticated or aren't using the correct URL.

There's an old example of curl to login in another forum post  - note the first GET ("request login") is important to load cookies before the authentication POST.

This works for Form-based authentication for Liberty with its user registry. I don't have a way to test against OIDC/JAS, or LDAP - these may require something different.

I couldn't get this old curl method to work against the 7.0.1 GA server I have to hand - below shows my updated version, there may be other ways to do this.

> including a "X-Jazz-CSRF-Prevent"

AFAICT a header X-Jazz-CSRF-Prevent is not required.

I am using -ssl as an argument and I think my servers all use TLSv1.2.  

Didn't need to do this, but I'm using a very recent curl based on latest OpenSSL library - did you try getting latest curl version? I'd have thought if there were any problem with the ssl?TLS connection that curl would simply fail to connect.

As Ralph says, it generally easiest to get the sequence to work using e.g. Postman in a browser, then depending on the REST app you may be able to see the operation as a curl command. You'll have to add the curl login cookies ( -b cookies.txt -c cookies.txt) to that command as shown below. The 'follow redirects' -L is a good idea to always include, it's certainly required for the initial GET and POST.

The XML to add fred to the admins is as per the process API docs

#Request login - get sessionid saved in cookies.txt - cookies.txt will be provided to and updated in each subsequent request
# get project areas
curl -k -L -b cookies.txt -c cookies.txt ""
# (not done with curl) in the result of previous request find project, find admins-url
# add fred as admin
curl  -k -L -b cookies.txt -c cookies.txt -H "Content-Type: application/xml" -H "Accept: application/xml" "" -d "<jp:admins xmlns:jp=''><jp:admin><jp:user-url></jp:user-url></jp:admin></jp:admins>"
The result of the POST is a 201 "Created" with a Location header pointing at the new admins entry:

NOTE this simple curl login will only be valid until the login expires but that's fine for a simple operation like above. A much better general approach is to authenticate when a response indicates authentication is needed, and this means re-authentication on token expiry happens automatically - not something you're going to do with curl.


Ralph Schoon commented Oct 12 '21, 2:42 a.m.

Please have the curtesy to accept this great answer. Thanks. 

permanent link
Ryan McBryde (5511130) | answered Oct 15 '21, 5:49 p.m.


Thank you very much for your thoughtful detailed answer. I took your examples and tried them. 

The response was an html document that started with:
<!DOCTYPE html>
  Licensed Materials - Property of IBM
  (c) Copyright IBM Corporation 2005, 2015. All Rights Reserved.

  Note to U.S. Government Users Restricted Rights:
  Use, duplication or disclosure restricted by GSA ADP Schedule
  Contract with IBM Corp.
Then I ran:
curl -k -L -b cookies.txt -c cookies.txt "https://server:9443/jts/j_security_check?j_username=x&j_password=x
        "userId": "x",
        "roles": [

Then ran:
curl  -k -L -b cookies.txt -c cookies.txt -H "Content-Type: application/xml" -H "Accept: application/xml" "https://ccm_server:9443/ccm/process/project-areas/_uDuqwPO_EeaBgvr3P04HHg/admins" -d "<jp:admins xmlns:jp=''><jp:admin><jp:user-url>https://jts_server:9443/jts/users/x</jp:user-url></jp:admin></jp:admins>

When I added -v to see the response I saw this:

HTTP/1.1 403 Forbidden

I am working version 6.0.1 running on WAS 8.5 and we are authenticating against LDAP.

I will take yours and Ralph's suggestion to use POSTMAN although I have never worked with it before and maybe it can shed some light.  I had originally written these scripts a couple of years ago and they were working as expected but apparently something has changed in our environment as best I can tell.  I started by writing a perl script that built the curl command to remove a user from a project area and then cycled through all the project areas where that user was a member.  Every now and them I would hit a failure to remove because I was not a project admin so I added the "X-Jazz-CSRF-Prevent" with the JSESSIONID to add my id to the project and then re-ran the remove user, and it was all working.   I was trying to adapt that to removing links and found that it wasn't working.  

Ralph Schoon commented Oct 16 '21, 7:58 a.m.

Use RESTCLIENT in Firefox I think you can login using the browser and then send the REST calls in RESTCLIENT you can also export to cURL later.

Please accept Ians answer, thanks.

Ian Barnard commented Oct 18 '21, 3:37 a.m. | edited Oct 18 '21, 3:41 a.m.

Hi Ryan

version 6.0.1 running on WAS 8.5 and we are authenticating against LDAP

That's an old version - I don't have access to a 6.0.1 env to try this out. But it looks like you are authenticated to jts from the response to the second curl.

Ah you're accessing /ccm. I believe ccm does its own authentication whereas rm delegates this to jts - try replacing /jts with /ccm

Your answer

Register or to post your answer.