Próbuję zrobić resztę, zadzwoń do dwóch różnych serwerów Jira, oba ta sama wersja 7.13.2
Dwa serwery to: jira2.xyz.com i jira3.xyz.com . Jestem zalogowany w nich obu.
jira2.xyz.com i jira3.xyz.com Zaloguj mnie za pomocą LDAP , gdy naciśnij przycisk logowania. Jedyną różnicą w procesie logowania dwóch serwerów jest to, że jira2.xyz.com bezpośrednio Loguje się za pośrednictwem tylko LDAP , gdy jira3.xyz.com Wymaga jednego dodatkowego kroku za pomocą powiadomienia duet włączone / włączenie hasła. Jednak krok DUO nie jest wymagany za każdym razem, gdy wyloguję się i zaloguj się do jira3.xyz.com (może być Duo prowadzi pewną sesję).
Kod, który przechodzi i daje oczekiwane wyjście:
result=$(curl -X GET --header "Accept: application/json" "https://jira2.xyz.com/rest/api/2/issue/ISSUE-29142?fields=status")
echo "Response from server ..." $result
echo "Key is : "
key=($( echo $result | jq .'key' ))
echo $key
exit
kod, który nie powiedzie się:
result=$(curl -X GET --header "Accept: application/json" "https://jira3.xyz.com/rest/api/2/issue/ISSUE-29089?fields=status")
echo "Response from server ..." $result
echo "Key is : "
key=($( echo $result | jq .'key' ))
echo $key
exit
W wyniku awarii produkuje poniższe wyjście błędów:
{"errorMessages":["You do not have the permission to see the specified issue.","Login Required"],"errors":{}}
Jak widać z góry, nie ma różnicy w kategoriach oprócz nazwy serwera.
Nie jestem pewien, dlaczego to dziwne zachowanie. Daj mi znać, jeśli myślisz, że przegapiłem o ważnych szczegółach. Rozwijam to na Windows 10.
Edytuj 1: Rozpocznij
Uruchamianie polecenia Curl z opcją -v dla Prodduces Jira3 poniżej wyjścia (starałem się jak najlepiej (dość trudne dla mnie, ponieważ nie jestem świetny w czytaniu dzienników sieciowych) i właśnie edytowałem niektóre wartości tylko po to, aby się upewnić, że nie rozdawam żadnego Szczegóły Nie powinienem):
Note: Unnecessary use of -X or --request, GET is already inferred.
* STATE: INIT => CONNECT handle 0x800012345; line 1491 (connection #-5000)
* Added connection 0. The cache now contains 1 members
* STATE: CONNECT => WAITRESOLVE handle 0x800012345; line 1532 (connection #0)
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Trying a1b1:1234:4321:5678::zz0:4b3:443...
* TCP_NODELAY set
* STATE: WAITRESOLVE => WAITCONNECT handle 0x800012345; line 1611 (connection #0)
* Connected to jira3.xyz.com (a1b1:1234:4321:5678::zz0:4b3) port 443 (#0)
* STATE: WAITCONNECT => SENDPROTOCONNECT handle 0x800012345; line 1667 (connection #0)
* Marked for [keep alive]: HTTP default
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* STATE: SENDPROTOCONNECT => PROTOCONNECT handle 0x800012345; line 1682 (connection #0)
{ [5 bytes data]
* TLSv1.3 (IN), TLS handshake, Server hello (2):
{ [87 bytes data]
* TLSv1.2 (IN), TLS handshake, Certificate (11):
{ [3155 bytes data]
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
{ [333 bytes data]
* TLSv1.2 (IN), TLS handshake, Server finished (14):
{ [4 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
} [70 bytes data]
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
} [1 bytes data]
* TLSv1.2 (OUT), TLS handshake, Finished (20):
} [16 bytes data]
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* TLSv1.2 (IN), TLS handshake, Finished (20):
{ [16 bytes data]
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
* subject: C=US; ST=Missouri; L=Kansas CIty; O=xyz Corporation; CN=*.xyz.com
* start date: Jun 4 16:43:33 2018 GMT
* expire date: Jun 4 17:13:32 2020 GMT
* subjectAltName: host "jira3.xyz.com" matched cert's "*.xyz.com"
* issuer: <Some issuer detail, which I just replaced by few random characters>
* SSL certificate verify ok.
* STATE: PROTOCONNECT => DO handle 0x800012345; line 1701 (connection #0)
} [5 bytes data]
> GET /rest/api/2/issue/ISSUE-29089?fields=status HTTP/1.1
> Host: jira3.xyz.com
> User-Agent: curl/7.66.0
> Accept: application/json
>
* STATE: DO => DO_DONE handle 0x800012345; line 1756 (connection #0)
* STATE: DO_DONE => PERFORM handle 0x800012345; line 1877 (connection #0)
{ [5 bytes data]
* Mark bundle as not supporting multiuse
* HTTP 1.1 or later with persistent connection
< HTTP/1.1 401
< X-AREQUESTID: 934x7042171x9
< X-ANODEID: node2
< X-XSS-Protection: 1; mode=block
< X-Content-Type-Options: nosniff
< X-Frame-Options: SAMEORIGIN
< Content-Security-Policy: frame-ancestors 'self'
< X-ASEN: SEN-8803321
* Added cookie atlassian.xsrf.token="ABCD-WXYZ-1234-4PWR_1f2g5s3gs52h7d645gh673h5Fg2F425gsty27856_lout" for domain jira3.xyz.com, path /, expire 0
< Set-Cookie: atlassian.xsrf.token=ABCD-WXYZ-1234-4PWR_1f2g5s3gs52h7d645gh673h5Fg2F425gsty27856_lout; Path=/; Secure
< X-AUSERNAME: anonymous
< Cache-Control: no-cache, no-store, no-transform
< WWW-Authenticate: OAuth realm="https%3A%2F%2Fjira3.xyz.com"
< Content-Type: application/json;charset=UTF-8
< Date: Mon, 23 Mar 2020 20:34:00 GMT
* Added cookie BIGipServer~Prod~pool_jira3_prd_8080="120400004.12345.8765" for domain jira3.xyz.com, path /, expire 0
< Set-Cookie: BIGipServer~Prod~pool_jira3_prd_8080=120400004.12345.8765; path=/; Httponly; Secure
* no chunk, no close, no size. Assume close to signal end
* Marked for [closure]: HTTP: No end-of-message indicator
<
{ [109 bytes data]
* nread <= 0, server closed connection, bailing
* STATE: PERFORM => DONE handle 0x800012345; line 2067 (connection #0)
* multi_done
100 109 0 109 0 0 56 0 --:--:-- 0:00:01 --:--:-- 56
* Closing connection 0
} [5 bytes data]
* TLSv1.2 (OUT), TLS alert, close notify (256):
} [2 bytes data]
* The cache now contains 0 members
Response from server ... {"errorMessages":["You do not have the permission to see the specified issue.","Login Required"],"errors":{}}
Key is :
null
Edytuj 2: koniec
2 odpowiedzi
Dokumentacja Jira w HTTPS: // Deweloper .atlassian.com / Chmura / JIRA / platforma / JIRA - rest- api - cookie- oparty uwierzytelniania / mówi:
" Reszty API Jiry jest chroniony tymi samymi ograniczeniami, które są dostarczane za pośrednictwem standardowego interfejsu internetowego JIRA. "
Powyższe oświadczenie zasadniczo oznacza, że jako serwer jira2 w tym przypadku jest skonfigurowany do uwierzytelnienia za pomocą AD , każde połączenie odpoczynku do tego serwera byłoby również uwierzytelnione przez AD ( , czyli Nie ma potrzeby dostarczania poświadczeń jawnie w żądaniu ) i jako jira3 jest skonfigurowany do użycia 2FA (reklama + DUO) , więc musimy zapewnić token API w celu uzyskania połączenia reszty, aby odnieść sukces.
zgodnie z dokumentacją:
Jeśli włączyć dwukierunkową weryfikację na koncie, który jest używany przez skrypty lub usługi, aby uzyskać dostęp do ATLASSIAN Cloud Reszta API, to konto nie będzie w stanie używać hasła do podstawowego uwierzytelniania przed reszta API. Zalecamy zamiast tego korzystać z tokenu API, chociaż administrator organizacji mógł wykluczyć odpowiednie konto z weryfikacji dwukierunkowej. Przeczytaj więcej o żetonach API.
Dokumentacja pokrewna na 2FA : HTTPS: // Confluence.atlassian.com/Cloud/two-step-Vefication-976161185.html.
Patrząc na komendę Curl, o której wspomniałeś, nie widzę żadnej nazwy użytkownika ani hasła.
Polecenie Curl powinno wyglądać tak:
curl -D- -u USERNAME:PASSWORD https://jira3.xyz.com/rest/api/2/issue/ISSUE-29089?fields=status
Może polecenie Curl jest udokumentowane w Jira2, ponieważ problemy są przeglądane (publiczne) bez konieczności logowania:
Spróbuj uzyskać dostęp do tego samego problemu Jira, który został pomyślnie odzyskany za pomocą odpoczynku. Spróbuj uzyskać dostęp do przeglądarki z URL w sesji trybu gościa z Chrome.
https://jira2.xyz.com/Browse/issue-29142.
Jeśli Jira2 przekierowała się do strony logowania, wyrzuć moją odpowiedź. Obecnie jest to moja jedyna diagnoza.
Podobne pytania
Nowe pytania
rest
REST (Representational State Transfer) to styl architektury oprogramowania dla rozproszonych systemów hipermedialnych, takich jak sieć WWW. Jego popularność wzrosła w stosunku do architektur RPC, takich jak SOAP, ze względu na nieodłączne oddzielenie klienta od serwera, wynikające z posiadania jednolitego interfejsu między heterogenicznymi systemami.