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

0
Asif Kamran Malick 23 marzec 2020, 17:52

2 odpowiedzi

Najlepsza odpowiedź

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.

0
Asif Kamran Malick 25 marzec 2020, 23:46

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.

1
AbdulKarim 25 marzec 2020, 22:10