How to get Authorization Bearer Token with curl or other unix tool - linux

I have a problem with getting Authorization Bearer Token value with unix tool like curl from site.
The problem is that I don't know how to get only this value 7FA733D2E75A962D1FED6D26989550BD. The value is different every time when i make a request (I mean it is not constant value).
I have necessary information for this request and when i try with some browser with cookie manager and put by hand cookie value it is work and get valid token.
Cookie value is:
mac=00%3A1A%3A79%3A40%3A07%3AFF
stb_lang=en
timezone=Europe%2FParis
Request URL is:
http://livegopanel.club:8080/portal.php?type=stb&action=handshake&token=&JsHttpRequest=1-xml
If I try to automate this job from linux console I am not able to get this token.
When I capture the tcp flow with wireshark get following information from process of getting valid token.
This is the request to site:
GET /portal.php?type=stb&action=handshake&token=&JsHttpRequest=1-xml HTTP/1.1
Accept: */*
User-Agent: Mozilla/5.0 (QtEmbedded; U; Linux; C) AppleWebKit/533.3 (KHTML, like Gecko) MAG200 stbapp ver: 4 rev: 2721 Mobile Safari/533.3
Referer: http://livegopanel.club:8080/c/
Accept-Language: en-US,*
Accept-Charset: UTF-8,*;q=0.8
X-User-Agent: Model: MAG254; Link: Ethernet
Host: livegopanel.club:8080
Cookie: mac=00%3A1A%3A79%3A40%3A07%3AFF; stb_lang=en; timezone=Europe%2FParis
Connection: Keep-Alive
And this is the response from site:
HTTP/1.1 200 OK
Date: Sat, 22 Feb 2020 09:22:53 GMT
Content-Type: text/javascript;charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
Set-Cookie: __cfduid=d538fd5b5e457f16e217ec8cf092ea2de1582363373; expires=Mon, 23-Mar-20 09:22:53 GMT; path=/; domain=.livegopanel.club; HttpOnly; SameSite=Lax
Cache-Control: no-store, no-cache, must-revalidate
Cache-Control: post-check=0, pre-check=0
Pragma: no-cache
CF-Cache-Status: DYNAMIC
Server: cloudflare
CF-RAY: 568fe5eebe337ea4-BUD
{"js":{"token":"7FA733D2E75A962D1FED6D26989550BD"}}
I try many variation with curl but not able to get the value. How to build the curl request or have is other way (script written on bash, perl, etc.) to do this?

If you have jq installed:
curl -s http://livegopanel.club:8080/portal.php\?type\=stb\&action\=handshake\&token\=\&JsHttpRequest\=1-xml | jq -r '.js.token'
jq is a swiss army knife for JSON, if you're going to be working with JSON on the command line, I recommend getting acquainted with jq. You can use https://jqplay.org to test your jq filters live.
Otherwise using sed:
curl -s http://livegopanel.club:8080/portal.php\?type\=stb\&action\=handshake\&token\=\&JsHttpRequest\=1-xml | sed 's/.*token":"\(.*\)".*/\1/g'

Related

Files.ReadWrite ROPC MS Graph API 403 Error Though Scope shows correct authorization

We have a use case in our corporation in which ROPC is deemed secure in which we upload a file to a sharepoint folder. The user has been granted the contributor role. When we log onto sharepoint as the user, she can upload a file.
However, when we try to do the same through our application, we are getting 403 forbidden. Looking at the token we get through ROPC, I see the following:
Files.ReadWrite User.Read profile openid email
Why are we then getting 403 Forbidden when we try to upload the file?
A few more pieces of info:
Consent has been granted by the Administrator for the Delegated permission of Files.ReadWrite.
Application Manifest has allowPublicClient set to true.
In testing this use case, we were able to retrieve a user profile without problem, but for some reason the Files.ReadWrite says not authorized although the user can upload a file no problem from within Sharepoint.
Screenshot of API Permissions:
Decoded token part 1:
Decoded token part 2:
Failing Request:
POST /v1.0/sites/92a99e5f-bb3e-4588-9461-d640b59d52e2/drives/b!X56pkj67iEWUYdZAtZ1S4hDhiQyamFVEj8y19ROdYOKYReOmD1sXSoDAvyFjD733/root:/Miriams%20Folder/FMW%20Management%20EM12c.pptx:/microsoft.graph.createUploadSession HTTP/1.1
SdkVersion: graph-java/v2.4.1
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJub25jZSI6InJNckJTQlBjNnlWZmVGVVZpbXhkYXEwdUpPMDNPQTFIWnZQQ01mV21uLUEiLCJhbGciOiJSUzI1NiIsIng1dCI6ImtnMkxZczJUMENUaklmajRydDZKSXluZW4zOCIsImtpZCI6ImtnMkxZczJUMENUaklmajRydDZKSXluZW4zOCJ9.eyJhdWQiOiJodHRwczovL2dyYXBoLm1pY3Jvc29mdC5jb20iLCJpc3MiOiJodHRwczovL3N0cy53aW5kb3dzLm5ldC83Y2I5M2QyOS0yZGRkLTQ5NDAtYTVjMC05NWM1MzY3NjJkOTAvIiwiaWF0IjoxNjA3MzU2NDk1LCJuYmYiOjE2MDczNTY0OTUsImV4cCI6MTYwNzM2MDM5NSwiYWNjdCI6MCwiYWNyIjoiMSIsImFjcnMiOlsidXJuOnVzZXI6cmVnaXN0ZXJzZWN1cml0eWluZm8iLCJ1cm46bWljcm9zb2Z0OnJlcTEiLCJ1cm46bWljcm9zb2Z0OnJlcTIiLCJ1cm46bWljcm9zb2Z0OnJlcTMiLCJjMSIsImMyIiwiYzMiLCJjNCIsImM1IiwiYzYiLCJjNyIsImM4IiwiYzkiLCJjMTAiLCJjMTEiLCJjMTIiLCJjMTMiLCJjMTQiLCJjMTUiLCJjMTYiLCJjMTciLCJjMTgiLCJjMTkiLCJjMjAiLCJjMjEiLCJjMjIiLCJjMjMiLCJjMjQiLCJjMjUiXSwiYWlvIjoiQVNRQTIvOFJBQUFBdUUvM3BaZjlXbE8ySWlaVkJlbzBURDFXK2VWR3o1RHN1YWNYRHF5VTU3WT0iLCJhbXIiOlsicHdkIl0sImFwcF9kaXNwbGF5bmFtZSI6ImFjY2VzcyBsZWVzIGZvbGRlciIsImFwcGlkIjoiOTkzNjQzNzktNDVhMC00ZGZhLTlkOTQtZDlhNDEwNTJjZDFjIiwiYXBwaWRhY3IiOiIwIiwiZmFtaWx5X25hbWUiOiJHcmFoYW0iLCJnaXZlbl9uYW1lIjoiTWlyaWFtIiwiaWR0eXAiOiJ1c2VyIiwiaXBhZGRyIjoiMjE2Ljk5LjE4MC4xNjMiLCJuYW1lIjoiTWlyaWFtIEdyYWhhbSIsIm9pZCI6IjZjODJiY2E3LTE5NjAtNGM1MS1iNjFjLWE3NDg3MTYyM2Y5ZiIsInBsYXRmIjoiMTQiLCJwdWlkIjoiMTAwMzIwMDBGMTZFRkNCRSIsInJoIjoiMC5BQUFBS1QyNWZOMHRRRW1sd0pYRk5uWXRrSGxETnBtZ1JmcE5uWlRacEJCU3pSeDFBTzAuIiwic2NwIjoiRmlsZXMuUmVhZFdyaXRlIG9wZW5pZCBwcm9maWxlIFJvbGVNYW5hZ2VtZW50LlJlYWQuQWxsIFJvbGVNYW5hZ2VtZW50LlJlYWQuRGlyZWN0b3J5IFVzZXIuUmVhZCBlbWFpbCIsInN1YiI6Im1MdTA4WFczc0RmNlF1c0lxZmVtRjViUUdySDlGYkRzQ0JLZ2w1RnljcXMiLCJ0ZW5hbnRfcmVnaW9uX3Njb3BlIjoiTkEiLCJ0aWQiOiI3Y2I5M2QyOS0yZGRkLTQ5NDAtYTVjMC05NWM1MzY3NjJkOTAiLCJ1bmlxdWVfbmFtZSI6Ik1pcmlhbUdAdDg3N3NyZi5vbm1pY3Jvc29mdC5jb20iLCJ1cG4iOiJNaXJpYW1HQHQ4NzdzcmYub25taWNyb3NvZnQuY29tIiwidXRpIjoiR3U5V2FfalRORXFHSUJrdS0xaTlBQSIsInZlciI6IjEuMCIsIndpZHMiOlsiYjc5ZmJmNGQtM2VmOS00Njg5LTgxNDMtNzZiMTk0ZTg1NTA5Il0sInhtc19zdCI6eyJzdWIiOiJDQTFnQkttVU9nLVplc3otMEFmOWF1VVFHOHY0a283MlNoVGp1eEFlSjFNIn0sInhtc190Y2R0IjoxNjAzNzI3NjA4fQ.x5xY4qWUKQdYNOwlj0GWP0f8ICT10ojCQ1CKUoffDYm2W5FGKUMOZPx11dhZv6W2ye1Tm0v3Yd6lMm9nWOkXf5LhILLmLptX1SCA7K0fQ-ttgZRhFrtPf3_sEycaTDMTSIS4WtoDlQ1Z3kjv17F0N56cxWnmZli9YFPJCD54YZZingBzfZI4pd96XvuE9aVaZiB1P92kg7veMIjYczgvDgMijtTSnVgzzF06Uip0eRG5oQhnmz1VwLG2djJFPeu6Xm2zvsIF4-FTxDzEmjq-JQVo2GupAUVxVtUyZyrEsGupu763gpEfOvkgusKPnByZdPXGA1cPksosAA0fe4kbnA
Accept: */*
SdkVersion: graph-java-core/v1.0.5 (featureUsage=0) java/1.8.0_131
client-request-id: edea4a1e-b722-4980-a688-ce1699af69bd
Content-Type: application/json
Content-Length: 11
Host: graph.microsoft.com
Connection: Keep-Alive
Accept-Encoding: gzip
User-Agent: okhttp/4.10.0-RC1
Failing Response (ROPC):
HTTP/1.1 403 Forbidden
Cache-Control: private
Content-Type: application/json
request-id: f00286fd-5ae6-488e-afd6-475ae7846906
client-request-id: edea4a1e-b722-4980-a688-ce1699af69bd
x-ms-ags-diagnostic: {"ServerInfo":{"DataCenter":"North Central US","Slice":"SliceC","Ring":"2","ScaleUnit":"000","RoleInstance":"AGSFE_IN_71"}}
Strict-Transport-Security: max-age=31536000
Date: Mon, 07 Dec 2020 15:59:59 GMT
Content-Length: 279
Successful Request (client_credentials)
POST /v1.0/sites/92a99e5f-bb3e-4588-9461-d640b59d52e2/drives/b!X56pkj67iEWUYdZAtZ1S4hDhiQyamFVEj8y19ROdYOKYReOmD1sXSoDAvyFjD733/root:/Miriams%20Folder/FMW%20Management%20EM12c.pptx:/microsoft.graph.createUploadSession HTTP/1.1
SdkVersion: graph-java/v2.4.1
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJub25jZSI6Imp0M3ZlaW5pVkZPZTc1R0I5RG40Uk0ydEJlWTRkUEZOYTFiaDQwR1RFMmMiLCJhbGciOiJSUzI1NiIsIng1dCI6ImtnMkxZczJUMENUaklmajRydDZKSXluZW4zOCIsImtpZCI6ImtnMkxZczJUMENUaklmajRydDZKSXluZW4zOCJ9.eyJhdWQiOiJodHRwczovL2dyYXBoLm1pY3Jvc29mdC5jb20iLCJpc3MiOiJodHRwczovL3N0cy53aW5kb3dzLm5ldC83Y2I5M2QyOS0yZGRkLTQ5NDAtYTVjMC05NWM1MzY3NjJkOTAvIiwiaWF0IjoxNjA3MzcyMDQxLCJuYmYiOjE2MDczNzIwNDEsImV4cCI6MTYwNzM3NTk0MSwiYWlvIjoiRTJSZ1lIZ2hFR1ZwODBpdXhmcFl2V3ZYa1Y4YUFBPT0iLCJhcHBfZGlzcGxheW5hbWUiOiJhY2Nlc3MgbGVlcyBmb2xkZXIiLCJhcHBpZCI6Ijk5MzY0Mzc5LTQ1YTAtNGRmYS05ZDk0LWQ5YTQxMDUyY2QxYyIsImFwcGlkYWNyIjoiMSIsImlkcCI6Imh0dHBzOi8vc3RzLndpbmRvd3MubmV0LzdjYjkzZDI5LTJkZGQtNDk0MC1hNWMwLTk1YzUzNjc2MmQ5MC8iLCJpZHR5cCI6ImFwcCIsIm9pZCI6IjllNWIzYzM1LWNjYzAtNDk5Zi04NjExLTA2Yjc2MmM0NzNlYiIsInJoIjoiMC5BQUFBS1QyNWZOMHRRRW1sd0pYRk5uWXRrSGxETnBtZ1JmcE5uWlRacEJCU3pSeDFBQUEuIiwicm9sZXMiOlsiU2l0ZXMuUmVhZFdyaXRlLkFsbCIsIkZpbGVzLlJlYWRXcml0ZS5BbGwiLCJVc2VyLlJlYWQuQWxsIl0sInN1YiI6IjllNWIzYzM1LWNjYzAtNDk5Zi04NjExLTA2Yjc2MmM0NzNlYiIsInRlbmFudF9yZWdpb25fc2NvcGUiOiJOQSIsInRpZCI6IjdjYjkzZDI5LTJkZGQtNDk0MC1hNWMwLTk1YzUzNjc2MmQ5MCIsInV0aSI6Ilg3aTdIa1N3VGttal9jMW5zbWNYQUEiLCJ2ZXIiOiIxLjAiLCJ4bXNfdGNkdCI6MTYwMzcyNzYwOH0.AIj32kpkwVZiU6OM038yb4m7KQkQZ65PYSYGgS0M_ONhymtxhq7c1XAY-oTTw6jSyApb7d8lI37er-Qi9f47KXvhfEZlrpG0lX4ZOBcuqbPQagOTETT6Tn6FI5LKtIRm7SP2rICNUNzLuXip5D3_3i4Oil0AENQfu4eLjXr6YA5yIfjp4JUx_Ylh8eV9B0QM-na2BZLdrI3RfM0SY2ifFArxcWKQoaNUDinHYE952Wb5-SdgiX16Bi5-dN6LJiIhu4kScn3pHVbbpunBbk7aDTaPaqFeO7uuLycPIIkbu7vStTVX0mmRUXeg2wL6bU9tWo5YT5X93hi7oMYpoyQkNg
Accept: */*
SdkVersion: graph-java-core/v1.0.5 (featureUsage=0) java/1.8.0_131
client-request-id: 147bd003-d380-49ec-aa5a-6f18adef0021
Content-Type: application/json
Content-Length: 11
Host: graph.microsoft.com
Connection: Keep-Alive
Accept-Encoding: gzip
User-Agent: okhttp/4.10.0-RC1
Successful Response (client_credentials)
HTTP/1.1 200 OK
Cache-Control: private
Content-Type: application/json;odata.metadata=minimal;odata.streaming=true;IEEE754Compatible=false;charset=utf-8
Location: https://graph.microsoft.com
Vary: Accept-Encoding
request-id: bc409fcf-f957-4477-8e02-05d06f4724f1
client-request-id: 147bd003-d380-49ec-aa5a-6f18adef0021
x-ms-ags-diagnostic: {"ServerInfo":{"DataCenter":"North Central US","Slice":"SliceC","Ring":"3","ScaleUnit":"002","RoleInstance":"AGSFE_IN_12"}}
OData-Version: 4.0
Strict-Transport-Security: max-age=31536000
Date: Mon, 07 Dec 2020 20:19:04 GMT
Content-Length: 1473
FOR SUCCESSFUL RUN, this is followed by
CONNECT t877srf.sharepoint.com:443 HTTP/1.1
Host: t877srf.sharepoint.com:443
Connection: Keep-Alive
User-Agent: okhttp/4.10.0-RC1
Plus all the chunking
Issue encountered was due to the simple fact that the folder we are uploading to is not the root folder. For root Folder, Files.ReadWrite is sufficient; for other folders the permission Files.ReadWrite.All is required.

Asana get /events

everyone!
I've got a problem with receiving data for request like "/events" (as described in https://asana.com/developers/api-reference/events). I sent GET request to https:/ /app.asana.com:443/api/1.0/events/ and got error 400 (bad request). For further information please see folowing details (token has been obfuscated)
Request:
GET /api/1.0/events/ HTTP/1.1
Authorization: Bearer 0/00000000000000000000000000000000
Host: app.asana.com
Response:
HTTP/1.1 400 Bad Request
Server: nginx
Date: Mon, 01 Feb 2016 10:01:43 GMT
Content-Type: application/json; charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
X-Asana-Content-String-Length: 215
Pragma: no-cache
Set-Cookie: TooBusyRedirectCount=0
Cache-Control: no-store
X-Asana-Preferred-Release-Revision: 20160130_055457_72a36bb0a264503a3e39ecea630b93bfff45340f
X-Robots-Tag: none
Response body:
d7
{"errors":[{"message":"resource: Missing input","help":"For more information on API status codes and how to handle them, read the docs on errors: https://asana.com/developers/documentation/getting-started/errors"}]}
Could you please advice me a solution to solve the issue?
According to the error message, you are missing the resource input.
Please consult https://asana.com/developers/api-reference/events to see how to use this feature.

HTTP 406 Error While Logging In To DocuSign API

I have a prototype WinForms application that uses open-source DocuSign.Integrations.Client library. It was working correctly until a couple of days ago. Now every attempt to login results in HTTP 406 error. No code has changed on my side, and my user name and password are valid (verified on https://appdemo.docusign.com). Any help is appreciated!
Below is the raw request with masked credentials:
GET http://demo.docusign.net/restapi/v2/login_information?api_password=true&include_account_id_guid=true
HTTP/1.1 Accept: application/json
Content-Type: application/json
X-DocuSign-Authentication: <DocuSignCredentials><Username>______</Username><Password>______</Password><IntegratorKey>____-________-___-___-___-____________</IntegratorKey></DocuSignCredentials>
Host: demo.docusign.net
Connection: Keep-Alive
In response, I get a 302 redirect:
HTTP/1.1 302 Found
Cache-Control: no-cache
Content-length: 0
Location: https://demo.docusign.net
Connection: close
And then receive a 406 error:
HTTP/1.1 406 Not Acceptable
Content-Type: text/html
Server: Microsoft-IIS/7.5
X-Powered-By: ASP.NET
Date: Sat, 09 May 2015 19:16:52 GMT
Content-Length: 1346
Connection: close
This is incorrect:
http://demo.docusign.net/restapi/v2/login_information?
api_password=true&include_account_id_guid=true
It should use HTTPS, not HTTP in your GET URL call:
https://demo.docusign.net/restapi/v2/login_information?
api_password=true&include_account_id_guid=true
Also your error is actually describes what is wrong
HTTP/1.1 406 Not Acceptable
Your request headers should be this:
Accept: application/json
Content-Type: application/json
X-DocuSign-Authentication: <DocuSignCredentials><Username>______</Username><Password>______</Password><IntegratorKey>____-________-___-___-___-____________</IntegratorKey></DocuSignCredentials>

Data attached to POST request is gone during redirection to GET with CURL

I wrote followed command to send POST with JSON data to server. The server must redirect my request and send GET with the same data:
curl -L -i -XPOST \
-d 'id=105' \
-d 'json={"orderBy":0,"maxResults":50}' http://mysite.com/ctlClient/
I get response:
HTTP/1.1 302 Found
Date: Thu, 04 Jul 2013 13:12:08 GMT
Server: Apache
X-Powered-By: PHP/5.3.19
Set-Cookie: PHPSESSID=1hn0g8d7gtfl4nghjvab63btmk2; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
location: http://mysite.com/fwf/online/
Content-Length: 0
Connection: close
Content-Type: text/html
HTTP/1.1 200 OK
Date: Thu, 04 Jul 2013 13:12:08 GMT
Server: Apache
X-Powered-By: PHP/5.3.19
Set-Cookie: PHPSESSID=16akc7kdcoet71ipjflk9o9cnm5; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Content-Length: 1
Connection: close
Content-Type: text/html
From access-log I see:
"POST /ctlClient/ HTTP/1.1" 302 - "-" "Apache-HttpClient/4.1 (java 1.5)"
"GET /fwf/online/ HTTP/1.1" 200 1 "-" "Apache-HttpClient/4.1 (java 1.5)"
So far so good,
The problem is that GET doesn't receives my data added to post. Sounds like during redirect my data dismissed somehow. From Android client it works, therefore its not Server side problem.
What I need to do to pass POST data to GET request?
Thank you very much,
[EDIT]
#nif offerd to upgrade CURL, i did , to 7.28.0.
Still get the same problem
[INFO]
1st time i go to http://mysite.com/ctlClient/index.php where:
case 105: // id=105
session_unset();
session_start();
foreach($_POST as $key => $value){$_SESSION[$key] = $value;}
ctlGotoSameDomain("/fwf/online/"); // <- aka redirect
return true;
after redirect i go to /fwf/online/index.php and there my request is empty:
public function __construct() {
$this->json = isset($_SESSION['json']) ? $_SESSION['json'] : null;
msqLogFile("fwf/post", Array('post' => 'Request: '.$this->json));
}
http://mysite.com/ctlClient/index.php get 2 parameters properly: id and json
From curl's manpage:
When curl follows a redirect and the request is not a plain GET (for example POST or PUT), it will do the following request with a GET if the HTTP response was 301, 302, or 303. If the response code was any other 3xx code, curl will re-send the following request using the same unmodified method.
Edit
I did some research and found out, that it might be a problem with your curl version. Newer version will honour the -XPOST option and will POST to the redirected location as well. But older versions had an own option for this, i.e. --post301 and --post302. According to their manpage:
--post301
Tells curl to respect RFC 2616/10.3.2 and not convert POST requests into GET
requests when following a 301 redirection. The non-RFC behaviour is ubiquitous
in web browsers, so curl does the conversion by default to maintain
consistency. However, a server may require a POST to remain a POST after such
a redirection. This option is meaningful only when using -L, --location
(Added in 7.17.1)
--post302
Tells curl to respect RFC 2616/10.3.2 and not convert POST requests into GET
requests when following a 302 redirection. The non-RFC behaviour is ubiquitous
in web browsers, so curl does the conversion by default to maintain
consistency. However, a server may require a POST to remain a POST after such
a redirection. This option is meaningful only when using -L, --location
(Added in 7.19.1)
References:
Following redirects with curl
HTTP RFC
I need to add -b to my script to enable the cookies. CURL by default doesn't use them and this issue caused to session ID change. Therefore no data transferred.
curl -b -L -i -X POST \
-d 'id=105' \
-d 'json={"orderBy":0,"maxResults":50}' http://mysite.com/ctlClient/
Now its working

Question on authentication in curl command

When I run the below curl command with --negotiate option I get the following error. Any idea why?
[Aug05 5:03am] pradeep#localhost:/tmp/pradeep> curl --negotiate -u : -k --verbose --head "http://something.domain.com/something/soething.action"
About to connect() to something.domain.com port 80 (#0)
Trying ip-address ... connected
Connected to something.domain.com (ip-address) port 80 (#0)
HEAD /something.action HTTP/1.1
User-Agent: curl/7.21.6 (i386-pc-solaris2.10) libcurl/7.21.6 OpenSSL/0.9.8j zlib/1.2.3
Host: something.domain.com
Accept: */*
< HTTP/1.1 401 Unauthorized
HTTP/1.1 401 Unauthorized
< Date: Fri, 05 Aug 2011 09:04:45 GMT
Date: Fri, 05 Aug 2011 09:04:45 GMT
< Server: Apache-Coyote/1.1
Server: Apache-Coyote/1.1
* gss_init_sec_context() failed: : KDC policy rejects requestWWW-Authenticate: Negotiate
WWW-Authenticate: Negotiate
< Set-Cookie: JSESSIONID=0E94E134D7401632EBB4D042B8934DCD; Path=/
Set-Cookie: JSESSIONID=0E94E134D7401632EBB4D042B8934DCD; Path=/
< Content-Type: text/plain
Content-Type: text/plain
* no chunk, no close, no size. Assume close to signal end
I am able to open the site normally from the browser etc. Why I am I not able to authenticate here? Can someone help me understand
Two things you can try:
Remove --head. You seem to want to send a GET request, not a HEAD request.
Don't forget to provide the credentials as with this example: -u pierre:secret

Resources