problem using curl to access work item API
Hi guys,
I'm trying to use the REST API provided by rtc 1.0.1 to operate work items following this article:
https://jazz.net/wiki/bin/view/Main/ResourceOrientedWorkItems
Also I donwload and install the curl to access the api following the examples in that article. But the result from curl call is incorrect. It returns http error code 408. Detail information is below.
curl command:
curl -D - -k -c c:\cookies.txt -d j_username=ADMIN -d j_p
assword=ADMIN https://localhost:9443/jazz/j_security_check
Command response:
HTTP/1.1 408 The time allowed for the login process has been exceeded. If you wi
sh to continue you must either click back twice and re-click the link you reques
ted or close and re-open your browser
Server: Apache-Coyote/1.1
Content-Type: text/html;charset=utf-8
Content-Length: 1554
Date: Tue, 21 Apr 2009 07:53:50 GMT
Connection: close
My os is windows xp.
Any ideas on this problem? Thanks very much!
I'm trying to use the REST API provided by rtc 1.0.1 to operate work items following this article:
https://jazz.net/wiki/bin/view/Main/ResourceOrientedWorkItems
Also I donwload and install the curl to access the api following the examples in that article. But the result from curl call is incorrect. It returns http error code 408. Detail information is below.
curl command:
curl -D - -k -c c:\cookies.txt -d j_username=ADMIN -d j_p
assword=ADMIN https://localhost:9443/jazz/j_security_check
Command response:
HTTP/1.1 408 The time allowed for the login process has been exceeded. If you wi
sh to continue you must either click back twice and re-click the link you reques
ted or close and re-open your browser
Server: Apache-Coyote/1.1
Content-Type: text/html;charset=utf-8
Content-Length: 1554
Date: Tue, 21 Apr 2009 07:53:50 GMT
Connection: close
My os is windows xp.
Any ideas on this problem? Thanks very much!
8 answers
Tomcat does not allow "drive-by" logins as described in the Wiki topic. This means that you can't send the user name and password directly to /j_security_check, without getting a cookie from Tomcat first.
You could access a protected resource using curl first and Tomcat will send back a cookie in the redirect to the login page. Make sure curl stores this cookie. Then proceed with the steps described in the Wiki topic.
You could access a protected resource using curl first and Tomcat will send back a cookie in the redirect to the login page. Make sure curl stores this cookie. Then proceed with the steps described in the Wiki topic.
You could access a protected resource using curl first and Tomcat will send back a cookie in the redirect to the login page. Make sure curl stores this cookie. Then proceed with the steps described in the Wiki topic.
I'm trying this and it still does not work
curl -D - -k -c %COOKIES% -d j_username=%USER% -d j_password=%PASSWORD% %HOST%/service/com.ibm.team.workitem.service.internal.roa.IRestService/workitems/1.xhtml
curl -D - -k -c %COOKIES% -d j_username=%USER% -d j_password=%PASSWORD% %HOST%/j_security_check
I wonder if it should work like this, using two invocations of curl.
The cookies file looks like this:
tisza.com FALSE /jazz TRUE 0 JSESSIONID C27CCF017B085CE898D4ABF2716458B2
tisza.com FALSE /jazz FALSE 0 JazzFormAuth Form
Why do I still get a 408?
Frank.
This will work for RTC 2.0 (perhaps 1.0.1 as well)
This is an example for retrieving work item 9:
This is an example for retrieving work item 9:
curl -v -k -L -b /tmp/cookies.txt -c /tmp/cookies.txt https://$HOST%/jazz/authenticated/identity
curl -v -k -L -b /tmp/cookies.txt -c /tmp/cookies.txt -d j_username=%USER% -d j_password=%PASSWORD% https://%HOST%/jazz/j_security_check
curl -v -k -L -b /tmp/cookies.txt -c /tmp/cookies.txt https://%HOST%/jazz/oslc/workitems/9.xml
I'm trying this and it still does not work
curl -D - -k -c %COOKIES% -d j_username=%USER% -d
j_password=%PASSWORD%
%HOST%/service/com.ibm.team.workitem.service.internal.roa.IRestService/workitems/1.xhtml
curl -D - -k -c %COOKIES% -d j_username=%USER% -d
j_password=%PASSWORD% %HOST%/j_security_check
I wonder if it should work like this, using two invocations of curl.
The cookies file looks like this:tisza.com FALSE /jazz TRUE 0 JSESSIONID C27CCF017B085CE898D4ABF2716458B2
tisza.com FALSE /jazz FALSE 0 JazzFormAuth Form
Why do I still get a 408?
I have updated the preliminary documentation for the 2.0 API with an
example of how to do Form Based auth with Tomcat:
https://jazz.net/wiki/bin/view/Main/ResourceOrientedWorkItemAPIv2
The example:
COOKIES=./cookies.txt
USER=username
PWD=password
HOST="https://localhost:9443/jazz"
curl -k -c $COOKIES "$HOST/authenticated/identity"
curl -k -L -b $COOKIES -c $COOKIES -d j_username=$USER -d j_password=$PWD
"$HOST/authenticated/j_security_check"
curl -k -b $COOKIES "$HOST/oslc/workitems/1.json"
--
Regards,
Patrick
Jazz Work Item Team
Hi there,
I read the page with the tips about using curl, and then also came across this topic. Just thought that I'd point out that $PWD is a variable that's used in unix environments to refer to your present working directory. So the command works, but there's a lot of scope to inadvertantly change what $PWD is set to be changing directory. Also, if like me you display at least some of your PWD in your PS1 prompt, you've just set your password to be very visible.
Changing the example to say $PASSWD might be safer overall.
Cheers,
Chris
I read the page with the tips about using curl, and then also came across this topic. Just thought that I'd point out that $PWD is a variable that's used in unix environments to refer to your present working directory. So the command works, but there's a lot of scope to inadvertantly change what $PWD is set to be changing directory. Also, if like me you display at least some of your PWD in your PS1 prompt, you've just set your password to be very visible.
c9law@mybox:dashboard $ cd /tmp/
c9law@mybox:tmp $ PWD=myPassw0rd
c9law@mybox:myPassw0rd $
Changing the example to say $PASSWD might be safer overall.
Cheers,
Chris
I read the page with the tips about using curl, and then also came
across this topic. Just thought that I'd point out that $PWD is a
variable that's used in unix environments to refer to your present
working directory. So the command works, but there's a lot of scope
to inadvertantly change what $PWD is set to be changing directory.
Also, if like me you display at least some of your PWD in your PS1
prompt, you've just set your password to be very visible.
c9law@mybox:dashboard $ cd /tmp/
c9law@mybox:tmp $ PWD=myPassw0rd
c9law@mybox:myPassw0rd $
Changing the example to say $PASSWD might be safer overall.
Thanks for pointing this out. I changed the example accordingly:
https://jazz.net/wiki/bin/view/Main/ResourceOrientedWorkItemAPIv2
--
Regards,
Patrick
Jazz Work Item Team
Has anyone done this using PERL?
I have these lines of PERL code
and the curl execution fails with this
curl: (60) SSL certificate problem, verify that the CA cert is OK. Details:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
More details here: http://curl.haxx.se/docs/sslcerts.html
curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn't adequate, you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
the -k (or --insecure) option.
If I run that same invocation from a windows command prompt I get successful execution and certs.
I have these lines of PERL code
my $curl = "d:/curl/bin/curl.exe" ;
my $COOKIES = "./cookies.txt" ;
unlink $COOKIES ;
$curlopts = "-k -c $COOKIES".' "https://rtpariadne.raleigh.ibm.com:9443/jazz/authenticated/identity"' ;
system($curl $curlopts) ;
and the curl execution fails with this
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
More details here: http://curl.haxx.se/docs/sslcerts.html
curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn't adequate, you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
the -k (or --insecure) option.
If I run that same invocation from a windows command prompt I get successful execution and certs.