Web services 当Android设备发出大量请求时，WEB API 2上出现401错误

我正在开发一个Android应用程序和一个可以通信的Web服务。我的Web服务位于Web API 2中，带有令牌承载身份验证

我的问题是，当我从Android应用程序向Web服务发送太多请求（15秒内约20个请求）时，WS-response

    “401” : “Authorization has been denied for this request”

这只发生在生产服务器（Amen hoster）和Android设备上。例如，如果我尝试与邮递员，一切都很好。因此，它与我的生产服务器和/或我的android应用程序请求有关

访问Web服务的代码

    URL obj = new URL(SERVEUR_URL + url);
    HttpURLConnection con = (HttpURLConnection) obj.openConnection();
    con.setRequestMethod("GET");
    con.setRequestProperty("Authorization", "Bearer " + token);
    con.setRequestProperty("Content-Type", "application/json");

    int responseCode = con.getResponseCode();
    String responseMessage = con.getResponseMessage();

Web服务上的身份验证提供程序是默认的。没有修改

来自我的Android应用程序的请求（并非每次都有效）

邮递员的请求（每次工作）

我所尝试的：

• 在本地复制此错误：它可以从android应用程序或Postman在本地服务器（web和SQL服务器）上正常工作
• 我检查每个请求中是否正确发送了令牌
• 来自Android的请求每次都是相同的
• 试图将缺少的标题添加到我的android应用程序请求中

我花了两天时间研究这个问题，读了很多stackoverflow帖子，但没有人帮我。 谢谢你的帮助

更新1:

对于Fiddler，我在邮递员的GET请求中看到，它们是一个Cookie头。当我们请求持币人代币时，会发送此cookie

来自服务器的令牌响应示例

    HTTP/1.1 200 OK
    Cache-Control: no-cache
    Pragma: no-cache
    Content-Length: 691
    Content-Type: application/json;charset=UTF-8
    Expires: -1
    Server: Microsoft-IIS/8.5
    Set-Cookie: .AspNet.Cookies=XXXX; path=/; HttpOnly
    X-Powered-By: ASP.NET
    X-Powered-By: ARR/2.5
    Date: Tue, 31 May 2016 16:55:39 GMT

            {"access_token":"XXXX","token_type":"bearer","expires_in":1209599,"userName":"Foo",".issued":"Tue, 31 May 2016 16:55:40 GMT",".expires":"Tue, 14 Jun 2016 16:55:40 GMT"}

Fiddler和Postman保存了这个cookie，并自动将其放入对API的请求中（例如“来自Postman的请求”代码块）。当我从邮递员获取请求中删除cookie时，它不起作用（就像我的android应用程序一样）

现在，问题是：为什么WebAPI2发送cookie而不是只使用令牌？为什么令牌在第一个请求中工作得很好，而在接下来的请求中却不能正常工作

从该页面底部可以看到，您的请求似乎总是经过身份验证，但有时无法获得授权

因此，在我看来，AuthorizationFilter[Authorize]以未知的原因拒绝了您的一些请求。我建议您转储API接收的请求以及附加到令牌的声明标识。试着看看当你有一个成功的回答和当你有一个401时，他们之间是否有差异

这样，您就可以确定是您的请求格式不正确，是索赔标识不好，还是授权筛选器出于其他原因（如太多查询或其他原因）拒绝了您

祝你好运

更新1 根据您的新输入，我认为您的Web API配置为同时使用令牌和cookie身份验证

我在这里看到的是，您有两种解决方案： 1°/将返回的cookie存储在Android应用程序中，并用于下一次呼叫。在不更改所有API的情况下解决问题的最简单、最快速的方法，但您存储了一个授权cookie：它可能导致安全问题（CSRF攻击）

2°/您可以检查您的身份验证和授权筛选器如何设置为禁用cookie身份验证并仅依赖令牌身份验证：因此，它将强制所有请求和API仅使用令牌，并将防止您遭受CSRF攻击。更复杂，因为您必须深入了解web API配置

检查以下链接（抱歉，因为我没有足够的声誉，每篇文章只能发布2个以上的链接，你可以在我的答案末尾找到它们作为文本）：

• ASP.net安全Web API 2.2[2]：来自底部“配置授权服务器”一章
• MSDN关于Web API安全性的文章[3]：有关Web API安全性、如何保护它和CRSF攻击的更多一般信息和技术信息

• StackOverflow.NET cookie和令牌身份验证[4]：检查David Banister的回答，我认为这正是您想要做的：只对所有API调用使用令牌

• StackOverflow授权过滤器和身份验证[5]：有关API的此类机制的更多信息

最后

• 使用web API和401代码进行Cookie身份验证[6]：听起来像是您的实际问题，不是吗

我希望它能帮助你，祝你好运

//链接

2:www.asp.net/web-api/overview/security/individual-accounts-in-web-api

3:msdn.microsoft.com/en-us/magazine/dn201748.aspx

4:stackoverflow.com/questions/22568409/mvc-net-cookie-authenticated-system-acessing-a-web-api-with-token-authentication

5:stackoverflow.com/questions/21231751/authorize-filter-and-authentication

---

6:brockallen.com/2013/10/27/using-cookie-authentication-middleware-with-web-api-and-401-response-codes/

最后，我得到了答案：

我的Web服务在我第一次请求请求时发送一个名为“dadaproaffinity”的Cookie。此Cookie是由邮递员自动提交给以下请求的，但不是由Android HttpUrlConnection提交的。所以，我只需要这个Cookie，现在我只需要在每个带有令牌的请求上添加这个Cookie

但是：此cookie由IIS发送，而不是由我的Web服务发送！这就是为什么它可以在本地服务器上工作，但不能在生产服务器上工作。我在谷歌上搜索了这块饼干，很少有人回应。我在英语中唯一找到的是：

    Technical Cookie of IIS Server hosting the site.
    Need to route to the correct server session, in order to keep it active

---

有人有关于此IIS Cookie的更多信息吗

两个请求之间的一个显著区别是缓存控制头。你试过在你的Android请求上设置吗？嗨，elevine，谢谢你的阅读。是的，我试过使用或不使用缓存控制，没有区别。谢谢，这有助于我找到新的线索。查看我的帖子更新Hello JohnB，我已经更新了我的答案。希望对你有帮助。谢谢你的帮助，我发现了

    HTTP/1.1 200 OK
    Cache-Control: no-cache
    Pragma: no-cache
    Content-Length: 691
    Content-Type: application/json;charset=UTF-8
    Expires: -1
    Server: Microsoft-IIS/8.5
    Set-Cookie: .AspNet.Cookies=XXXX; path=/; HttpOnly
    X-Powered-By: ASP.NET
    X-Powered-By: ARR/2.5
    Date: Tue, 31 May 2016 16:55:39 GMT

            {"access_token":"XXXX","token_type":"bearer","expires_in":1209599,"userName":"Foo",".issued":"Tue, 31 May 2016 16:55:40 GMT",".expires":"Tue, 14 Jun 2016 16:55:40 GMT"}

    Technical Cookie of IIS Server hosting the site.
    Need to route to the correct server session, in order to keep it active