2025-12-18, 13:08
  #1
Medlem
moohs avatar
Jag försöker köra ett curl-anrop mot en webbtjänst, men det blir bara fel. Det funkar inte från PHP och det funkar inte heller direkt ifrån CLI.

Även utvecklaren "på andra sidan", dvs de som utvecklat tjänsten förstår inte vad som är fel. Här är en anonymiserad men i övrigt komplett print out av anropet och svaret. Alla anonymiserade bitar är dubbel-trippelkollade av mig, utvecklaren på "andra sidan" samt av både ChatGPT och Grok, så allt sånt är korrekt.

Båda AI-tjänsterna, vars kunskaper man ska ta med en nypa salt, säger att användarnamn/lösenord är fel, men det är dom inte. Men likväl får vi 401 unauthorized som svar. Vi har provat med en speciell användare med ett mycket komplicerat, men regelrätt, lösenord, och även med en testanvändare med användarnamn i stil med ABC och lösenord DEF utan framgång. Jag är PHP-programmerare och kan egentligen väldigt lite om hur CURL fungerar och absolut inget om NTLM etc. När jag berättat för AI att username och password ÄR rätt, så kommer de med "det kanske är något annat" eller att man har fel verision av CURL eller att jag gör rätt och det är webbtjänsten som gör fel. Jag har ingen aning. Så egentligen skulle jag väl bara uppskatta om någon som är expert på sånt här tar en titt och kanske kan se "men DÄR är felet, dumskalle".

Kod:
[root@HOSTNAME ~]# curl -v \
  --ntlm \
  -u 'DOMAIN\USERNAME:PASSWORD' \
  -H 'Company: COMPANY_NAME' \
  -H 'Content-Type: application/json' \
  -d '{}' \
  http://SERVER_HOST:PORT/APP/ODataV4/OrderHandling_CreateOrder

* About to connect() to SERVER_HOST port PORT (#0)
*   Trying PRIVATE_IP...
* Connected to SERVER_HOST (PRIVATE_IP) port PORT (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* Server auth using NTLM with user 'DOMAIN\USERNAME'
> POST /APP/ODataV4/OrderHandling_CreateOrder HTTP/1.1
> Authorization: NTLM <NTLM_TYPE1_TOKEN>
> User-Agent: curl/7.29.0
> Host: SERVER_HOST:PORT
> Accept: */*
> Company: COMPANY_NAME
> Content-Type: application/json
> Content-Length: 0
>
< HTTP/1.1 401 Unauthorized
< Content-Length: 0
< Server: Microsoft-HTTPAPI/2.0
< WWW-Authenticate: NTLM <NTLM_TYPE2_TOKEN>
< Date: Thu, DD Mon YYYY HH:MM:SS GMT
<
* Connection #0 to host SERVER_HOST left intact
* Issue another request to this URL: 'http://SERVER_HOST:PORT/APP/ODataV4/OrderHandling_CreateOrder'
* Found bundle for host SERVER_HOST: 0xXXXXXXXX
* Re-using existing connection! (#0) with host SERVER_HOST
* Connected to SERVER_HOST (PRIVATE_IP) port PORT (#0)
* Server auth using NTLM with user 'DOMAIN\USERNAME'
> POST /APP/ODataV4/OrderHandling_CreateOrder HTTP/1.1
> Authorization: NTLM <NTLM_TYPE3_TOKEN>
> User-Agent: curl/7.29.0
> Host: SERVER_HOST:PORT
> Accept: */*
> Company: COMPANY_NAME
> Content-Type: application/json
> Content-Length: 2
>
* upload completely sent off: 2 out of 2 bytes
< HTTP/1.1 401 Unauthorized
< Content-Length: 0
< Server: Microsoft-HTTPAPI/2.0
* NTLM handshake rejected
* Authentication problem. Ignoring this.
< WWW-Authenticate: NTLM
< Date: Thu, DD Mon YYYY HH:MM:SS GMT
<
* Connection #0 to host SERVER_HOST left intact
[root@HOSTNAME ~]#
Citera
2025-12-18, 15:50
  #2
Medlem
Connykrims avatar
Är det basic auth? Eller via bearer?
Citera
2025-12-18, 19:11
  #3
Medlem
kalkryggars avatar
De "på andra sidan" som kör detta har de problem med andra eller är det bara med dig?

Vad händer om de sätter godkänt på lösenord utan att köra det i processen utan bara godkänna lösenordet?
Citera
2025-12-18, 20:57
  #4
Medlem
Lagerkommandants avatar
Citat:
Ursprungligen postat av mooh
Trådstart
Jag försöker köra ett curl-anrop mot en webbtjänst, men det blir bara fel. Det funkar inte från PHP och det funkar inte heller direkt ifrån CLI.
...

Har du försäkrat dig om att klient och server kör samma teckenkodning?
T.ex. charset UTF-8 eller annat.
Lätt hänt att lösenord uppfattas som felaktiga om inte teckenkodningen är den samma på båda sidor.
__________________
Senast redigerad av Lagerkommandant 2025-12-18 kl. 21:01.
Citera
2025-12-18, 21:55
  #5
Medlem
(Du verkar köra som root användare, kanske någon säkerhetsspärr ivägen; som inte tillåter root att hämta hem saker via curl?)

Endel med inloggningsproblem har föreslagit följande:
Kod:
curl --ntlm --negotiate -u username:mypassword
Låta curl sköta förhandlingen. Och inget "Domain" utan bara username.

Andra lägger till --http2
Kod:
curl --ntlm -u andrei:password --http2

Det är inte så att du ansluter via VPN, som kanske blockerar av någon anledning?
Citera
2025-12-18, 22:19
  #6
Medlem
Angående -H.
Från manualen.

You should not replace internally set headers without
knowing perfectly well what you are doing. Remove an
internal header by giving a replacement without content on
the right side of the colon, as in: -H "Host:". If you send
the custom header with no-value then its header must be
terminated with a semicolon, such as -H "X-Custom-Header;"
to send "X-Custom-Header:".

Citera
2025-12-19, 10:39
  #7
Medlem
moohs avatar
Tack alla som har svarat. Problemet har löst sig.

Jag är som sagt inte speciellt duktig på CURL (jag är mer i nivå med "kopiera något som funkar och försök köra det själv").

Det visar sig att jag misstolkade svaret ifrån CURL som (av någon anledning jag fortfarande inte förstår) svarar unauthorized även då jag skickar med rätt username/password.

AI förklarar det dock så här (om det stämmer till 100% eller ens alls vet jag inte - "lita aldrig på AI")

Step 1: Knock on door → "Who are you?" → 401
Step 2: Show ID → "Wait, check it again" → 401 (sometimes)
Step 3: Verified → Let you in → 500 (oops, backend crashed)

Om jag förstår detta rätt, och om det faktiskt stämmer, så verkar det som de två första 401-felen jag får är helt i sin ordning och att förvänta sig, även om det känns konstigt.

Och sen var det ett 500-fel som FAKTISKT gjorde att "inget kom in" till webbtjänsten. Jag upptäckte att jag saknade ett fält i den XML som skickades in - enligt uppgift skulle detta fält vara valfritt, men tydligen var det inte så.

När jag skickar in den uppdaterade XML:en så får jag nu istället
401
401
200 (istället för 500)

och jag ser i backend att datan verkligen har kommit in.
Citera
2025-12-19, 16:31
  #8
Medlem
Tips är att ta hem ett program för att testa API-frågorna innan du börjar sätta dig och koda. Typ Postman.

I de flesta fall kan du säkerligen även ta ut ett korrekt anrop via exempelvis curl där du kunnat säkerställa innan att det faktiskt fungerar.
Citera
2025-12-19, 17:36
  #9
Medlem
Enterprises avatar
Verkar amatörmässigt att numera använda denna typ av autentisering:
-u 'DOMAIN\USERNAME:PASSWORD' \

Dessutom "http" (okrypterat)?

Kanske signifikativt för tjänsten i övrigt också?
__________________
Senast redigerad av Enterprise 2025-12-19 kl. 17:39.
Citera
2025-12-27, 07:18
  #10
Medlem
moohs avatar
Citat:
Ursprungligen postat av kexchoklad123
Tips är att ta hem ett program för att testa API-frågorna innan du börjar sätta dig och koda. Typ Postman.

I de flesta fall kan du säkerligen även ta ut ett korrekt anrop via exempelvis curl där du kunnat säkerställa innan att det faktiskt fungerar.

Det var faktiskt precis vad jag gjorde och efter ett litet tag kunde jag lista ut vad som var fel.

AI tipsade mig om vad som var fel. Om AIs tips stämmer eller inte, vet jag dock inte. Personligen tycker jag det LÅTER knasigt att det skulle funka så här, men jag har inte fått någon bättre förklaring.

Curl-anropet, som för mig känns/ser ut som ett kommando, är i själva verket något som utförs i tre steg.. Så här ungefär:

Step 1: Knock on door → "Who are you?" → 401
Step 2: Show ID → "Wait, check it again" → 401 (sometimes)
Step 3: Verified → Let you in → 500 (oops, backend crashed)

Så även om man skickar in helt rätt info, så får man ändå två 401 INNAN man är authenticerad och datan har skickats in. Eftersom jag inte kan sånt här så hängde jag upp mig på de 401-fel jag fick och insåg inte att det inte var det som var det faktiska problemet.
Citera

Skapa ett konto eller logga in för att kommentera

Du måste vara medlem för att kunna kommentera

Skapa ett konto

Det är enkelt att registrera ett nytt konto

Bli medlem

Logga in

Har du redan ett konto? Logga in här

Logga in