Azure-docs: Не удалось подтвердить домен издателя

Привет, @xkobal, спасибо за ваш отзыв, в настоящее время мы изучаем этот вопрос и свяжемся с вами в ближайшее время.

Привет, @xkobal, не могли бы вы предоставить конфигурации, которые вы используете? Не могли бы вы также предоставить скриншот ошибки, которую вы видите?

Вот скриншот ошибки. Код ошибки изменился с моей первой попытки.

Какая конфигурация вам нужна?

Я вижу, какой идентификатор приложения вы используете? Вы уверены, что идентификатор приложения правильный?

Вот страница с полным доменным именем и идентификатором приложения. если вы попытаетесь скрутить URL-адрес, вы увидите, что идентификатор приложения соответствует тому, который указан на странице.

Я понимаю, это новое приложение AAD или это более старая регистрация приложения AAD?
Если вы создадите новую регистрацию приложения aad, получите ли вы ту же ошибку?

Здравствуйте:
У меня такая же проблема. Я создал новое приложение и получил ту же ошибку. Мой тип приложения - Регистрация каналов ботов.

Я понимаю, это новое приложение AAD или это более старая регистрация приложения AAD?
Если вы создадите новую регистрацию приложения aad, получите ли вы ту же ошибку?

Это старая регистрация приложения AAD. То же самое и с другим приложением.

привет @xkobal и @ seagull33, мы сейчас изучаем эту проблему и сообщим вам, что делать дальше. Спасибо, что сообщили нам об этом,

Здравствуйте, @xkobal и @ seagull3, можете ли вы попробовать создать или использовать пользователя, который был недавно создан или создан после того, как был создан

Я создал еще одно приложение с вызовом "test", 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):

Это ошибка, которая у меня:

Не удалось проверить домен издателя. Ошибка при получении файла JSON с https://genial.ly/.well-known/microsoft-identity-association. Сервер вернул непредвиденное значение заголовка типа контента. [snhlT]

Подскажите, пожалуйста, что не так? Благодаря!

Здравствуйте,

Это ошибка, отличная от той, о которой идет речь в исходной проблеме 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 со ссылкой на эту проблему.

Благодаря,

• Франк Ху

@ 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, а затем создали клиент AAD с той же учетной записью MSA. Если вы создали приложение AAD не таким способом, изучите различные варианты решения вашей проблемы.

Мы изучаем эту проблему и работаем над ее решением,

Еще раз прошу прощения за проблемы, которые это может вызвать.

Поскольку эта проблема с github была решена в рамках этой проблемы, я закрою эту проблему с github к концу дня. Если у вас возникнут какие-либо проблемы, напишите о новой проблеме на github со ссылкой на эту проблему на github.

У меня такая же проблема. Я попробовал работу, которая, как мне кажется, предлагается в этой теме.

Я создал нового пользователя AAD по имени Qwiqr.

А затем я создал новую регистрацию приложения, принадлежащую новому пользователю AAD.

Когда я пытаюсь подтвердить домен, я все равно получаю эту ошибку ...

«Ошибка проверки домена издателя. Ошибка при получении файла JSON с https://qwiqr.co.uk/.well-known/microsoft-identity-association. Сервер вернул неожиданное значение заголовка типа содержимого. [PMOxq]»

Тип контента - «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 make волшебным образом работает

@ FrankHu-MSFT

Эта проблема по-прежнему возникает при размещении файла на страницах GitHub:

Поскольку нет контроля над типом контента, используемым GitHub Pages, каково решение для этого, учитывая, что конечный пользователь не имеет контроля над GitHub Pages и типом контента, настроенным для файлов.

Не удалось проверить домен издателя. Файл JSON, расположенный по адресу www.mydomain.com/.well-known/microsoft-identity-association.json, имеет длину содержимого, которая не установлена ​​или недействительна по другим причинам. [E / SIR]

Скачайте только что из Azure и поместите в мой домен, но все равно не удалось. Есть новости по этому поводу?

Здесь та же проблема. Postman и Chome указывают, что тип контента - «application / json». Я попытался создать нового пользователя на портале, как вы предложили, но это не устранило проблему.
Мой файл размещен на сервере Apache.

@neobie , вы

Я получаю ту же ошибку, что и @abraunegg, при размещении страницы на страницах GitHub с

Когда я копирую и вставляю следующую ссылку, я вижу 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/en-us/answers/questions/13291/publisher-domain-verification-fails-because-verifi.html?childToView=14181#comment -14181

Я попытался решить эту проблему в трех разных областях, как указано выше ... похоже, все люди не заинтересованы в исправлении этой проблемы.

Спасибо за обновление @abraunegg , да, я вижу, что вы и другие очень тщательно

у меня возникла мысль ... проверить домен другим способом:

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

Итак, я просто выполнил первые два шага, то есть добавил текстовую запись в домен и проверил.

Я _did_ не_ продолжал добавлять больше записей для электронной почты и т. Д. (Потому что мне не нужна эта настройка).

А затем, когда я вернулся на страницу брендинга приложения и щелкнул Update Domain , домен был там в списке проверенных доменов:

Отказ от ответственности: я понятия не имею, приведет ли это к каким-либо непредвиденным / нежелательным последствиям, но, по крайней мере, я мог бы проверить домен и выбрать его.

@oshihirii
Этот процесс работает только в том случае, если вы являетесь владельцем домена и можете добавить запись TXT. Если вы размещаете проверочный JSON на github - через страницы github ... вы не можете следовать этому процессу ...

Проблема ясна, решение ясное - MS необходимо обновить проверку, чтобы игнорировать кодировку, если она установлена ​​.. очень легко сделать и исправить.

@abraunegg - ах, извините, я вижу, я забыл, что у вас нет для него

(на случай, если кому-то это понадобится, и я уверен, что есть сотни других конкурентов, у 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 Этот канал документации лучше всего подходит для создайте запрос в службу поддержки . Первоначальная проблема, поднятая здесь, была решена, и, похоже, есть вторая проблема, которая не связана с документацией, и открытие запроса в службу поддержки является подходящим действием.
На этой неделе я работаю дежурным специалистом, и моя роль заключается в том, чтобы предоставить первоначальный ответ и перенаправить проблему в нужную команду. Если эта функциональность продукта не работает должным образом, запрос в службу поддержки является наиболее эффективным каналом для решения проблемы. Если документация не работает, я рекомендую открыть новый выпуск, и мы можем работать с командой разработчиков, чтобы обновить документацию. Если вы открываете новую проблему, не забудьте указать, что шаги, описанные в документации, не приводят к заявленным функциям, и включите подробности о вашей реализации за вычетом любой конфиденциальной информации. Я ценю ваше понимание.

К сожалению, предлагаемое решение, изложенное здесь https://github.com/MicrosoftDocs/azure-docs/issues/39665#issuecomment -538104258, на данный момент неэффективно. Это может быть результатом дальнейших изменений серверной части системы проверки на стороне Microsoft, но на данном этапе закрытие заявки неуместно. Я отправил подробности заголовка в @ FrankHu-MSFT, как это было запрошено в соответствующей ветке документации, и с нетерпением жду последующих сообщений.

Я сбит с толку, что эта ошибка не исправлена. charset - это часть заголовка http в Интернете. Вы это вообще тестировали? Большинство людей не могут удалить заголовок кодировки на своих ресурсах. Пожалуйста, уволите стажера, который написал и протестировал этот кусок дерьма.

Это снова "не совсем совместимый" стандартный режим работы Microsoft. Просто исправь, хорошо? Почему событие заботится о заголовке? Простых обходных путей и явной ошибки нет.

Для меня код ошибки был IL2U4. Я исправил это, перейдя в IIS, MIME-типы и изменив тип для .JSON на «application / json». Довольно смешно, насколько плохи сообщения об ошибках Microsoft. И в любом случае, почему тип MIME вообще имеет значение? Программисты в Microsoft просто действительно некомпетентны, я видел это тысячей разных точек зрения на протяжении десятилетий.

У меня такая же проблема ... это ошибка, никаких "если" и "но" по этому поводу. Это нелепое количество времени, которое разработчики приложений тратят на отладку, поиск в Интернете и попытки изменить основные принятые стандарты, чтобы они соответствовали этому нелепому ограничению. Квалификация даже не имеет смысла.

Повторяя комментарий, который я видел в другом месте, безусловно, требуются только следующие проверки:

1. Файл json существует в нужном месте?
2. Содержит ли он ожидаемый идентификатор приложения?

Кодировка не имеет значения. . Исправьте эту ошибку, пожалуйста.

Учитывая , что этот вопрос закрыт _и_ первоначальный вопрос не имеет никакого отношения к комментариям остальным из нас , имеющих, я создал новый вопрос здесь .