时间戳

首页 > 解决方案 > 类似的 rest 调用表现不同：成功调用一个 Jira 服务器，而另一个 Jira 服务器登录错误

rest - 类似的 rest 调用表现不同：成功调用一个 Jira 服务器，而另一个 Jira 服务器登录错误

问题描述

我正在尝试对两个不同的 Jira 服务器进行休息 GET 调用，它们都是相同的版本 7.13.2

这两个服务器是：jira2.xyz.com和jira3.xyz.com。我登录到他们两个。

jira2.xyz.com和jira3.xyz.com都通过LDAP登录，当我点击登录按钮时。两台服务器登录过程的唯一区别是jira2.xyz.com仅通过LDAP直接登录，而jira3.xyz.com需要通过启用DUO的推送通知/输入密码的额外步骤。但是，每次我注销并重新登录jira3.xyz.com时都不需要 DUO 步骤（可能是 DUO 维护了一些会话）。

通过并给出预期输出的代码：

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

失败的代码：

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

由于失败，它会产生以下错误输出：

{"errorMessages":["You do not have the permission to see the specified issue.","Login Required"],"errors":{}}

从上面我们可以看出，除了服务器名称之外，代码没有任何区别。

不知道为什么会出现这种奇怪的行为。如果您认为我错过了任何重要的细节，请告诉我。我正在Windows 10 上开发这个。

编辑 1：开始

为 jira3 运行带有 -v 选项的 curl 命令会产生以下输出（我已经尽力了（对我来说非常困难，因为我不擅长阅读网络日志）并且只是编辑了一些值以确保我没有给出任何细节我不应该）：

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

编辑 2：结束

标签： restshellcurlldapjira

解决方案

查看您提到的 curl 命令，我没有看到任何用户名或密码。

curl 命令应如下所示：

curl -D- -u USERNAME:PASSWORD  https://jira3.xyz.com/rest/api/2/issue/ISSUE-29089?fields=status

也许 curl 命令在 jira2 中成功，因为问题是可浏览的（公共的），无需登录：

尝试访问使用 rest 成功检索的相同 Jira 问题。尝试在 chrome 的访客模式会话中使用带有 url 的浏览器进行访问。

https://jira2.xyz.com/browse/ISSUE-29142

如果 Jira2 重定向到登录页面，则丢弃我的答案。目前这是我唯一的诊断。

推荐阅读