Azure-docs: 验证发布者域失败

嘿@xkobal，感谢您的反馈，目前我们正在对此进行调查，并将尽快与您联系。

嘿@xkobal您可以提供正在使用的配置吗？ 您还可以提供所见错误的屏幕截图吗？

这是错误的屏幕截图。 自我第一次尝试以来，错误代码已更改。

您需要什么配置？

我知道，您使用的应用程序ID是什么？ 您确定应用程序ID正确吗？

这是具有完整域名和应用程序ID的页面。 如果您尝试卷曲URL，您将看到应用ID与页面上的ID相对应。

我知道，这是新的AAD申请还是旧的AAD申请注册？
如果您创建新的aad应用注册，是否会遇到相同的错误？

您好：
我有同样的问题。 我创建了一个新的应用程序，并遇到相同的错误。 我的应用程序类型是Bot Channels Registration。

我知道，这是新的AAD申请还是旧的AAD申请注册？
如果您创建新的aad应用注册，是否会遇到相同的错误？

这是旧的AAD申请注册。 与另一个应用程序相同。

嘿@xkobal和@ seagull33我们目前正在调查此问题，并将让您知道解决此问题的后续步骤。 感谢您通知我们

您好@xkobal和@ seagull3您可以尝试创建或使用新创建的用户，还是在您所在的AAD租户创建后创建的用户，然后尝试再次进行验证？

我创建了另一个应用程序调用“测试”，ID：“ dc0a40ac-6182-4563-ade8-5e8174ed6343”

错误是相同的。

我在第一条消息中忘记了一点，当我单击“验证并保存域”时，对托管文件没有调用。

嘿@xkobal澄清不是新的应用程序。 请尝试在新创建的AAD租户中使用新用户，或者在创建AAD租户后创建

嗨，我在这里遇到同样的问题...这是我的域验证端点：

https://genial.ly/.well-known/microsoft-identity-association.json

我已经调整了Express NodeJS应用程序以将Content-Type返回到“ application / json”，但是我无法删除字符集部分（Express软件包的安全性原因）：

这是我的错误：

发布者域验证失败。 从https://genial.ly/.well-known/microsoft-identity-association获取JSON文件时出错

你能告诉我出什么问题了吗？ 谢谢！

你好，

这是与原始github问题所指的错误不同的错误。
每个文档的@chemitaxis必须是application / json。 不适用于内容类型charset = utf-8。 您将需要从nodeJS服务器的标头中删除该标头。

感谢@ FrankHu-MSFT。 如果另一个由于Node的相同问题而来，我使用以下代码解决了该问题：

res.writeHead(200, {
      'Content-Type': 'application/json'
    });

    res.write(
      JSON.stringify({
        associatedApplications: [
          {
            applicationId: 'XXXXXXXX-24f7-XXXX-XXXX-7bd7583f1ce8'
          }
        ]
      })
    );
    res.end();

感谢您在此线程上提供您的解决方案！ 我们绝对感谢@chemitaxis ！

嘿@xkobal和@ seagull3我正在关注这个问题。 您能否确认在AAD租户中使用新用户的解决方案是否可以解决问题？

如果明天结束之前没有任何回应，我将关闭此问题。

如果您还有其他问题，请参考此问题打开一个新的git问题。

谢谢，

• 胡Hu

@ FrankHu-MSFT，因为我的应用程序是“来自个人帐户的应用程序”，如果我创建另一个用户，它可以看到我的应用程序，因此无法测试。

@ FrankHu-MSFT，您好：通过电子邮件与您联系后，我被重定向至Github问题。 我们遇到此处描述的相同问题。
我刚刚创建了一个新用户（具有“应用程序管理员”权限），但恐怕该用户无法看到原始应用程序（这是“来自个人帐户的应用程序”）：

嘿，@ pierrepinard-2 @xkobal @ seagull33发生这种情况的原因是因为无法利用个人帐户中的应用程序来验证该应用程序。

您将需要在新的AAD用户下创建一个新的AAD应用程序，

也就是说，当您按照这些步骤的应用程序域验证将无法正常工作：

1. 使用MSA帐户创建一个新应用； 关闭窗口
2. 注册Azure
3. 完成注册/试用后，再次进入门户。 转到“ Azure AD”并确认已创建新的租户
4. 转到“应用程序注册”，选择“来自个人帐户的应用程序”，选择应用程序，然后尝试验证域

不幸的是，这种功能不起作用。 您将需要在新创建的AAD租户中的新AAD用户下创建一个新应用。

造成您的不便，敬请见谅。

@ FrankHu-MSFT对我来说，这是一个主要问题，个人帐户的应用程序无法验证其域
同时为应用程序用户显示警告：-/
我唯一的选择是重新创建应用程序，这对我们的用户来说是一个问题，方法是强制用户再次同意其他应用程序...

你好@xkobal我理解这一点，对于由此引起的问题表示歉意。 不幸的是，这是此类问题的唯一解决方案。

请注意，这仅适用于在MSA帐户下创建应用程序注册，然后再使用相同的MSA帐户创建AAD租户的用户。 如果这不是您创建AAD应用程序的方式，则请探索其他选项来解决您的问题。

我们正在研究这个问题，并正在努力解决，

对于可能造成的问题，我再次表示歉意。

由于此github问题已在此问题范围内得到解决，因此我将在当天结束时关闭此github问题。 如果您还有其他问题，请提交新的github问题，并对此github问题进行引用。

我有同样的问题。 我已经尝试过该线程中建议的解决方法。

我创建了一个名为Qwiqr的新AAD用户。

然后，我创建了一个属于新AAD用户的新应用注册。

当我尝试验证域时，仍然出现此错误...

“发布者域的验证失败。从https://qwiqr.co.uk/.well-known/microsoft-identity-association获取JSON文件时出错

内容类型是“ application / json”，我在其他地方看到过。

HTTP/1.1 200 OK
Cache-control: no-cache="set-cookie"
Content-Language: en
Content-Type: application/json
Date: Tue, 15 Oct 2019 16:04:02 GMT
Server: Apache/2.4.39 (Amazon) mod_wsgi/3.5 Python/3.6.8
Set-Cookie: AWSELB=A9FDA12F0E5ABFD665AA7054525B2A118275F6A0D1F813AE4AF9762AAD4DE5A9B64B6626B247E5F93E6ABADADDD0A462AC6A62F598F8EF4CE5AE338FB5953711E64A2BA028;PATH=/;MAX-AGE=600
Vary: Accept-Language,Cookie
x-content-type-options: nosniff
X-Frame-Options: SAMEORIGIN
x-xss-protection: 1; mode=block
Content-Length: 93
Connection: keep-alive

我还尝试为新用户赋予“应用程序管理员”角色，这也没有帮助。

我的应用程序使用django。 这是我第一次尝试使用Azure，即使开始使用它，我也没有多大运气。 有什么建议吗？

只是想提到，对于express.js用户，完全像这样编写代码确实可以使它工作。 我以前写过这样的代码：

res.end(<JSON CONTENT HERE>)

即使我正确设置了content-type标头，验证仍然失败。 但是，将代码更改为☝️just上面的代码段是神奇的工作

@ FrankHu-MSFT

在GitHub Pages上托管文件时，仍然会出现此问题：

由于无法控制GitHub Pages使用的内容类型-鉴于最终用户无法控制GitHub Pages和为文件配置的内容类型，该解决方案是什么？

发布者域验证失败。 位于www.mydomain.com/.well-known/microsoft-identity-association.json的JSON文件的内容长度未设置或无效。 [E / SIR]

从Azure重新下载并放入我的域，但仍然失败。 这事有进一步更新吗？

在这里有同样的问题。 Postman和Chome指示内容类型为“ application / json”。 我尝试按照您的建议在门户中创建一个新用户，但这不能解决问题。
我的文件托管在Apache服务器上。

@neobie ，您是否有机会解决了您的问题？

在具有自定义域的GitHub页面上托管页面时，出现与@abraunegg相同的错误。

当我复制并粘贴以下链接时，我可以看到JSON，所以我知道它在那里：

https://my-domain-here.com/.well-known/microsoft-identity-association.json

它只是一个简单的HTML/CSS/JS单页应用程序，没有Node后端或类似的东西。

_（注意：根据这篇文章，我必须在项目根目录中添加一个.nojekyll文件，以便使该文件位于.well-known文件夹中，可通过url访问）_

编辑：

这里有相关的讨论：

https://stackoverflow.com/a/33619500

其中引用：

https://github.com/jshttp/mime-db

并且看起来.json文件已以正确的类型返回，因此看起来这是一个Azure问题，而不是GitHub页面问题：

https://github.com/jshttp/mime-db/blob/master/src/nginx-types.json#L11

@ oshihirii ， @ veler ，@ neobie
只需添加以下内容即可： https: //docs.microsoft.com/zh-CN/answers/questions/13291/publisher-domain-verification-fails-because-verifi.html = 14181#comment -14181

我试图按照上述方法在3个不同的区域中解决此问题...所有人员似乎都没有兴趣解决此问题。

感谢@abraunegg的更新，是的，我可以看到您和其他人在研究问题和阐明所有要点方面做得非常透彻，希望很快就能完成。

我有一个想法...以另一种方式验证域：

https://docs.microsoft.com/zh-cn/microsoft-365/admin/setup/add-domain?view=o365-worldwide

因此，我所做的只是完成前两个步骤，即将文本记录添加到域并进行验证。

我_没有_继续为电子邮件等添加更多记录（因为我不需要该设置）。

然后，当我返回到应用程序的品牌页面并单击Update Domain ，该域就在“已验证的域”列表中：

免责声明：我不知道这是否会带来一些意想不到的后果，但是至少我可以验证该域并选择它。

@oshihirii
仅当您拥有域并可以添加TXT记录时，该过程才有效。 如果您在github上通过github页面托管验证JSON ..您将无法遵循该过程...

问题很明显，解决方案很明确-如果设置了字符集，MS需要更新验证以忽略字符集..非常容易执行和修复。

@abraunegg-对不起，我明白了，我忘记了您没有自定义域（我有，但是也托管在GitHub页面上）。 是的，我认为您的结论似乎正确。

（以防万一有人需要它，我敢肯定还有其他数百个竞争对手，namesilo.com拥有便宜的域名注册（带有DNS管理），或者您可以使用更基本的域名注册商，然后再使用cloudflare（添加文本记录等）） 。

@ FrankHu-MSFT
所以..问题又回来了……Microsoft何时会解决此问题？

我们也开始在我们的某些Azure订阅中看到这一点。 以过去几年的相同方式验证域已无法正常工作，但出现以下错误：

Verification of publisher domain failed. The JSON file located at [YOUR_URL].com/.well-known/microsoft-identity-association.json has a content length that is not set or otherwise invalid. [hTCyp]

作为参考，这种方法已经使用了很长时间。 直到最近，当我们需要验证另一套应用程序时，它才因上述消息而失败。 确实似乎是Azure的问题，或者验证工作方式发生了一些变化。

@ Mike-Ubezzi-MSFT
我们能在这里得到一些牵引修复这个问题？

@abraunegg此文档通道最适合提出文档问题。 如果有特定的文档问题，请打开一个新的问题，我将其重定向到Identity and Security工程团队以解决该文档。 如果您遇到产品问题，请创建支持请求。 此处提出的原始问题已解决，似乎还有第二个问题不是特定于文档的，打开支持请求是可以采取的适当措施。
我是本周的待命资源，我的角色是提供初始响应并将问题重定向到正确的团队。 如果这是产品功能无法正常工作，则支持请求是解决问题的最有效渠道。 如果文档不起作用，那么我建议打开一个新的期刊，我们可以与内容团队合作更新文档。 如果您打开一个新问题，请确保指出，文档中详细介绍的步骤不会导致所述功能，并且包括有关您的实施的详细信息以及任何敏感信息。 感谢您的理解。

不幸的是，这里所阐述的建议的解决方案https://github.com/MicrosoftDocs/azure-docs/issues/39665#issuecomment -538104258在这一点上是无效的。 这可能是由于在Microsoft端对验证系统进行了后端进一步更改而导致的，但是在这一点上，关闭票证是不合适的。 我已按照相关文档线程中的要求将标头详细信息转发到@ FrankHu-MSFT，并期待后续工作。

我对这个错误尚未修复感到困惑。 charset是Internet上http标头的一部分。 你有没有测试过？ 大多数人无法删除其资源上的字符集标头。 请解雇撰写和测试此事的实习生。

再次是微软的“不太兼容”标准操作模式。 修好，好吗？ 为什么事件关心标题？ 没有简单的解决方法和明显的错误。

对我来说，错误代码是IL2U4。 我通过进入IIS，MIME类型并将.JSON的类型更改为“ application / json”来修复了它。 多么糟糕的Microsoft错误消息是非常荒谬的。 在任何情况下，MIME类型为何都如此重要？ 微软的程序员真的很无能，在过去的几十年中，我以千种不同的方式看到了它。

我有同样的问题...这是一个错误，没有关于它的假设。 这太荒谬了，应用程序开发人员必须花费大量时间进行调试，搜索互联网并尝试修改公认的核心标准以符合此荒谬约束。 资格甚至没有意义。

呼应我在其他地方看到的评论，肯定只需要进行以下检查：

1. json文件是否存在于正确的位置？
2. 它是否包含预期的应用程序ID？

字符集不重要。 。 请修复此错误。

鉴于此问题已关闭－原始问题与我们其他人的评论无关，所以我在这里创建了一个新问题。