排除错误未找到认证挑战
我正在尝试使用一些遗留代码，并且在使用抽球时遇到了一个问题。
我试图去看看我们的主站点有api，它对一个帐户可以正常工作，但不是另一个帐户。 我试图找出请求URL /头文件中的差异，以及回复中的内容，但我似乎无法在抽象代码中找到将这些内容打印到日志中的方法。
我得到的错误是
com.android.volley.NoConnectionError: java.io.IOException: No authentication challenges found
我已经读过这可能是由于401响应，但我不知道这意味着什么，或至少如何证明/测试。 我真的很困惑，它适用于一个帐户，而不是另一个帐户。
网址与我们的英国网站和其他网站的网址略有不同，但除此之外没有区别。
谢谢
事实上，我通过在服务器响应中包含WWW-Authenticate头来解决了这个问题。
但是，如果添加标头WWW-Authenticate: Basic realm=""并且您的API也被Web客户端使用，则某些Web浏览器将触发弹出窗口询问基本凭据。
对我来说，正确的解决方案一直使用定制方案。 正如本博文中所解释的，我在标题响应中使用了xBasic而不是Basic 。
WWW-Authenticate: xBasic realm=""
有了这个头文件，Volley不仅可以正确解析响应，还可以避免Web浏览器显示身份验证弹出窗口。
发生此错误是因为服务器发送401（未授权），但未给出“WWW-Authenticate”，这是客户提示下一步要做什么。 “WWW-Authenticate”标题告诉客户需要哪种认证（Basic或Digest）。 对于无头HTTP客户端来说，这通常不是很有用，但这就是标准的定义。 发生此错误的原因是lib试图解析“WWW-Authenticate”标题，但不能。
如果可以更改服务器，可能的解决方
WWW-Authenticate: Basic realm="fake" 。 这仅仅是一种解决方法，不是解决方案，但它应该起作用并且http客户端很满意。 403而不是401 。 它的语义是不一样的，通常当使用登录401是一个正确的答案（详细讨论见这里），但它足够接近。 如果您无法更改服务器，可能的解决方案是：
正如@ErikZ在他的文章中写道的，你可以使用try＆catch
HttpURLConnection connection = ...;
try {
// Will throw IOException if server responds with 401.
connection.getResponseCode();
} catch (IOException e) {
// Will return 401, because now connection has the correct internal state.
int responsecode = connection.getResponseCode();
}
我也在这里发布这个：java.io.IOException：没有发现认证的挑战
初始化抽象RequestQueue时，我能够抓住这个客户端：
Volley.newRequestQueue(getApplicationContext(), new HurlStack() {
@Override
public HttpResponse performRequest(Request<?> request, Map<String, String> additionalHeaders) {
try {
return super.performRequest(request, additionalHeaders);
} catch (AuthFailureError authFailureError) {
authFailureError.printStackTrace();
// Log out / whatever you need to do here
} catch (IOException e) {
e.printStackTrace();
if (e.getMessage().equals("No authentication challenges found")) {
// This is the error. You probably will want to handle any IOException, not just those with the same message.
}
}
return null;
}
});
上一篇: volley error No authentication challenges found
下一篇: A distinct HTTP status for not logged in vs. not authorized in a RESTful API