Observed unknow behavior while using REST-Service url with curl script in IBM ALM server
Our developer teams have provided one REST service url (syntax below) to get the components details from the stream:
https<servername>/service/xyz.server.scm.metadata.IPersistWorkspaceMetadataService?StreamName=<Stream-name>&SnapshotName=<lSnaphot-name>
This service has been deployed on alm-007 server and alm-008 server. So, the service is available on both server.
And the above Rest service call, I am call on command prompt with below script.
set USER=ABC
set PWD=****
set COOKIES=cookies.txt
curl.exe -k -c %COOKIES% https:// alm-007/cm/authenticated/identity
curl.exe -k -L -b %COOKIES% -c %COOKIES% -d j_username=%USER% -d j_password=%PWD% https:// alm-007/cm /authenticated/j_security_check
curl.exe -k -b %COOKIES% "https:// alm-007/cm/service/ service/xyz.server.scm.metadata.IPersistWorkspaceMetadataService?StreamName=PQR_JKL-FS_Stream1&SnapshotName= PQR_JKL-FS_Snapshot1" -o output.txt
With alm-007 server the above script is working fine, all the information I can see on the generated output.txt file. But in case of alm-008 server same script is not working.
Its say authfailed. Response script from server in command prompt
<html>
<body>
………
…………
/ <![CDATA[ /
require(["dojo/ready", "dojo/parser", "dijit/registry", "dijit/Dialog"], function(ready, parser, registry){
ready(function(){
net.jazz.ajax.ui.PlatformUI.createAndRunWorkbench("net.jazz.web.app.authfailed");
});
});
/ ]]> /
</script>
</body>
What will be region for this. I couldn’t be able to understand the behavior of server. Or Is my approach is wrong ?
Note : Both the server has SSO.
One answer
You receive this response when you are not correctly sending Authentication information to the API. I have two blog posts that explain both Oauth1.0a and OIDC authentication with ELM servers... Here's OIDC - API Authentication Method in ELM – OIDC and here's OAuth1.0a API Authentication Method in ELM – Oauth 1.0a
Comments
But how come its working for one server address and for another doesn't. In above example for alm-007 its working but for alm-008 its not working, with same user id and similar kind of server setup.
Ideally it should work for both or non of one.
The authentication code looks suspiciously like you are trying to use form based authentication and not SSO.
My advice would be to use Postman and to make sure the authentication actually works against both servers, before proceeding.
For example see https://rsjazz.wordpress.com/2021/10/15/elm-authentication/ to get an idea how the different authentication dances are.
SSO has BASIC Auth as a fallback as far as I understand.
I'm not aware that the curl approach is unviable (i.e. if it works it works), but AFAIK this sequence only works for Liberty FORM authentication, this two-step method GET then POST does the essential steps same as your browser with curl being told to follow 302 redirects on the POST by option -L
The curl method doesn't have any way to detect that auth failed and branch to handle that. Most likely what's going wrong is either that alm-008 has different username/password, or is configured to use JAS (OIDC) - then this curl method fails much like trying to blindly use OIDC auth when JAS isn't configured.
Using of Curl/Postman make any difference? It is all about authenticated only.
"Because this server is connected to an external user registry, some user details including User ID, E-Mail Address, and Repository Permissions are read-only. To modify these read-only details, you must make the changes in the external user registry"
Is this can be a region for this issue?
You need to be authenticated to do the next steps. You can Firefox RESTClient to authenticate and then do the next calls. This makes it easy to ignore the complexity of authentication. But you still do not know how to execute it in cURL.
In Postman and cURL, you need to know how to authenticate and that depends on the target system you work against. Form based, basic authentication as fallback. I shared my blog, if you are interested read it. Make sure you can authenticate with POSTman and then extract the cURL configuration.
I wonder why you can't get the information how to login or if the systems are configured against the same user management from your administrators.
Note, even if the password is correct and the same for each system, if the one server uses Form Based Authentication and the other uses SSO or another of the supported options, you would need to use different authentication options in cURL.
You might find out something about the authentication sequence for each server by recording a HAR file in your browser while logging in, and (manually) comparing the sequences looking for major differences.