【问题标题】:Mysterious 401 challenge when using AJAX使用 AJAX 时的神秘 401 挑战
【发布时间】:2019-09-28 07:19:55
【问题描述】:

我有一个托管在网络上的 .NET Core Web 应用程序。

我正在通过 cookie 使用基于声明的身份验证:

登录成功时...

var principal = new ClaimsPrincipal();
var id = new ClaimsIdentity(user);
id.AddClaim(new Claim("ViewData", "Allowed"));
id.AddClaim(new Claim("TenantId", user.TenantId));
principal.AddIdentity(id);
await HttpContext.SignInAsync(CookieAuthenticationDefaults.AuthenticationScheme, principal);

这一切都适用于除一个用户之外的每个用户 - 但是,当这个特定用户(第 3 方)与特定页面交互时,他们的浏览器中会出现身份验证弹出窗口(他们已经尝试了一些) -其他所有页面都可以正常工作。

这让我相信问题是环境问题,但我想了解这里可能发生的情况。

所讨论的页面与其他所有页面之间的唯一区别是,该页面执行 AJAX 发布到控制器以保存一些数据。 Home 控制器需要授权才能查看(或编辑)数据。

[Authorize(Policy = "ViewData")]

Ajax 是您的标准配置

剃须刀:

$.ajax({
  type: 'POST',
  url: '@Url.Action("_Save", "Home")',
  dataType: 'json',
  contentType: 'application/json',
  data: ko.toJSON(viewModel.model()),
  success: function (result) {
  //... callback code etc

检查呈现的 JS 表明 AJAX 调用是相对于当前页面的,因此不会转到一些奇怪的 URL

原始 JS:

$.ajax({
  type: 'POST',
  url: '/Home/_Save',
  dataType: 'json',
  contentType: 'application/json',
  data: ko.toJSON(viewModel.model()), // ... etc

当我查看浏览器时,我可以看到 cookie 包含在标题中:

accept: application/json, text/javascript, */*; q=0.01
accept-encoding: gzip, deflate, br
accept-language: en-GB,en-US;q=0.9,en;q=0.8
cache-control: no-cache
content-length: 4775
content-type: application/json
cookie: <cookie details here>

不幸的是,作为第 3 方,我无法真正连接到机器以查看浏览器的调试控制台。

我的问题确实是一个长镜头 - 听起来可能是代理问题,但我不明白为什么发出 AJAX 调用与发出登录 POST 请求有什么不同,除非我的 AJAX 设置当然丢失了一些需要的身份验证数据 - 可能是某种标题?

有没有人见过这样的东西?

【问题讨论】:

  • 您的操作名称正确吗?我看到你把_Save放在这里
  • 是的,它是正确的,它适用于 99% 的用户,只有特定网络上的一个用户有问题。
  • 那么你可以调用 ajax 到你的控制器吗?
  • 所有细节都在问题中 - 我认为没有任何缺失的信息。如问题中所述,它适用于除一个特定用户之外的多个网络中的每个用户。
  • 嗯,也许是一些防火墙或 ip 配置?

标签: ajax authentication asp.net-core cookies


【解决方案1】:

我遇到过类似的问题,它们通常与安全设置有关。您可以尝试查看 CSRF 标头。这可能是几件事。这可能包括本地防病毒软件、机器防火墙、反间谍软件或其他隐私/保护应用程序。由于它是单个用户,因此调试起来非常困难,我建议您弄清楚该用户的安全设置/应用程序与他们的同事有何不同。

将您的站点添加到特定浏览器中的受信任站点列表可能会解决单个问题。几乎可以肯定它隐藏在其中。

【讨论】:

  • 感谢您的信息。这实际上是每个用户的不同网络(它是第 3 方供应商门户),因此每个用户都在不同的基础架构上。我正在尝试让第 3 方从调试控制台向我发送一些详细信息,希望这至少可以向我展示拦截请求的内容。没有跨站点调用 - 它只是从当前引荐来源到同一 URL 上的另一条路由的 XHR 调用,所以我试图绕开会阻止这种情况的方法。听起来请求最终会解析到另一个主机 - 登录弹出窗口非常奇怪......
  • 给你赏金,因为我相信这是问题所在 - 只是想让其他人说出我的想法,它在一周左右后自行修复,没有对网站进行任何更改,所以我怀疑与网络相关的某些东西不太信任该网站。
  • 我的意思是,我很感激,很抱歉没有人想出一个神奇的现场解决方案。前端 Web 开发既烦人又困难,或者任何人都可以做得很好。
【解决方案2】:

嗯,这在一段时间后自行解决了 - 我相信它可能与网络有关。

第 3 方一周后再次尝试,这次没有问题。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2020-09-29
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2018-09-18
    • 1970-01-01
    • 2013-12-21
    • 2014-12-21
    相关资源
    最近更新 更多