Azure-docs: A verificação do domínio do editor falhou

Olá @xkobal, obrigado por seus comentários, no momento estamos investigando isso e entraremos em

Ei @xkobal, você poderia fornecer as configurações que está usando? Você também poderia fornecer uma captura de tela do erro que está vendo?

Aqui está uma captura de tela do erro. O código de erro mudou desde minha primeira tentativa.

Que configuração você precisa?

Entendo, qual é o ID do aplicativo que você está usando? Tem certeza de que o ID do aplicativo está correto?

Aqui está a página com o nome de domínio completo e o ID do aplicativo. se você tentar enrolar o URL, verá que o Id do aplicativo corresponde ao da página.

Entendo, este é um novo aplicativo AAD ou um registro de aplicativo AAD mais antigo?
Se você criar um novo registro de aplicativo aad, receberá o mesmo erro?

Olá:
Eu tenho o mesmo problema. Criei um novo aplicativo e recebi o mesmo erro. Meu tipo de aplicativo é registro de canais de bot.

Entendo, este é um novo aplicativo AAD ou um registro de aplicativo AAD mais antigo?
Se você criar um novo registro de aplicativo aad, receberá o mesmo erro?

É um registro de aplicativo antigo do AAD. É o mesmo com outro aplicativo.

Ei @xkobal e @ seagull33 , estamos investigando esse problema e informaremos as próximas etapas para resolvê-lo. Obrigado por nos informar sobre isso,

Olá @xkobal e @ seagull3, você pode tentar criar ou usar um usuário que foi criado recentemente ou criado depois que o locatário AAD em que você está foi criado e tente fazer a verificação novamente?

Criei outra chamada de aplicativo 'teste', id: "dc0a40ac-6182-4563-ade8-5e8174ed6343"

O erro é o mesmo.

Esqueci um ponto na minha primeira mensagem, quando clico em "Verificar e salvar domínio", não há chamada no arquivo hospedado.

Ei @xkobal para esclarecer que não é um novo aplicativo. tente usar um NOVO USUÁRIO no locatário do AAD que foi criado recentemente ou criado após a criação do locatário do AAD.

Olá, estou tendo o mesmo problema aqui ... aqui está meu endpoint para minha verificação de domínio:

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

Eu adaptei meu aplicativo Express NodeJS para retornar o Content-Type para 'application / json', mas não consigo remover a parte do conjunto de caracteres (motivos de segurança do pacote Express):

Este é o erro que tenho:

A verificação do domínio do editor falhou. Erro ao obter o arquivo JSON de https://genial.ly/.well-known/microsoft-identity-association. O servidor retornou um valor de cabeçalho de tipo de conteúdo inesperado. [snhlT]

Você pode me dizer o que está errado? Obrigado!

Olá,

Este é um erro diferente daquele ao qual o problema original do github se refere.
@chemitaxis de acordo com o documento, deve ser application / json. Não funcionará com o tipo de conteúdo charset = utf-8. Você precisará remover isso de seus cabeçalhos no servidor nodeJS.

Obrigado @ FrankHu-MSFT. Se outro veio aqui com o mesmo problema com o Node, resolvi o problema com este código:

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

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

obrigado por fornecer sua solução neste tópico! Nós definitivamente apreciamos isso @chemitaxis !

Olá @xkobal e @ seagull3 , estou acompanhando esse problema. Você pode confirmar se a solução de usar um novo usuário no locatário do AAD resolve o problema?

Se não houver resposta até o final do dia de amanhã, encerrarei esta questão.

Se você tiver mais problemas, abra um novo problema git com uma referência a este problema.

Obrigado,

• Frank Hu

@ FrankHu-MSFT como meus aplicativos são "Aplicativos de conta pessoal", se eu criar outro usuário, ele pode ver meus aplicativos, então não posso testar.

Olá @ FrankHu-MSFT, Fui redirecionado para este problema do Github depois de falar com você por e-mail. Encontramos o mesmo problema descrito aqui.
Acabei de criar um novo usuário (com direitos de "Administrador do aplicativo"), mas infelizmente este usuário não consegue ver o aplicativo original (que é um "aplicativo de conta pessoal"):

Ei @ pierrepinard-2 @xkobal @ seagull33, infelizmente, isso está acontecendo porque um aplicativo de uma conta pessoal não pode ser utilizado para verificar o aplicativo.

Você precisará criar um novo aplicativo AAD sob o novo usuário AAD,

Quando você seguir estas etapas, a verificação de domínio do aplicativo NÃO funcionará:

1. Crie um novo aplicativo com a conta MSA; janela fechada
2. Inscreva-se no Azure
3. Acesse o portal novamente após concluir a inscrição / avaliação. Vá para "Azure AD" e confirme a criação do novo locatário
4. Vá para "Registro do aplicativo", selecione "Aplicativos da conta pessoal", selecione Aplicativo e tente verificar o domínio

Infelizmente, esse tipo de funcionalidade não funciona. Você precisará criar um novo aplicativo em um novo usuário AAD no locatário AAD recém-criado.

Peço desculpas pelo transtorno. Informe se isso resolve o seu problema.

@ FrankHu-MSFT Para mim, é um grande problema que os aplicativos de contas pessoais não podem verificar seu domínio
enquanto um aviso é exibido para usuários do aplicativo: - /
Minha única opção é recriar aplicativos, o que é um problema para nossos usuários, forçando-os a dar novamente seu consentimento para outro aplicativo ...

olá @xkobal Eu entendo isso e peço desculpas pelos problemas que isso está causando. Infelizmente, essa é a única solução que existe para esse tipo de problema.

Observe que isso é apenas para usuários que criaram o registro do aplicativo em uma conta MSA e depois criaram um locatário AAD com a mesma conta MSA. Se não foi assim que você criou um aplicativo AAD, explore diferentes opções para resolver seu problema.

Estamos investigando esse problema e trabalhando para resolvê-lo,

Peço desculpas novamente pelos problemas que isso pode causar.

Como este problema do github foi resolvido dentro do escopo deste problema, encerrarei este problema do github no final do dia. Se você tiver mais problemas, registre um novo problema do github com uma referência a este problema do github.

Eu tenho o mesmo problema. Eu tentei a solução que acho que está sendo sugerida neste tópico.

Criei um novo usuário AAD chamado Qwiqr.

E então eu criei um novo registro de aplicativo pertencente ao novo usuário AAD.

Quando tento verificar o domínio, ainda recebo este erro ...

"A verificação do domínio do editor falhou. Erro ao obter o arquivo JSON de https://qwiqr.co.uk/.well-known/microsoft-identity-association. O servidor retornou um valor de cabeçalho de tipo de conteúdo inesperado. [PMOxq]"

O tipo de conteúdo é "application / json", que vi ser necessário em outro lugar.

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

Também tentei atribuir ao novo usuário a função de administrador do aplicativo ", o que também não ajudou.

Meu aplicativo usa django. Esta é minha primeira tentativa de usar o Azure e não estou tendo muita sorte ao começar com isso. Alguma sugestão, por favor?

Só queria mencionar que, para usuários de express.js, escrever o código exatamente como este faz com que funcione. Eu já havia escrito o código como:

res.end(<JSON CONTENT HERE>)

e a verificação ainda falhou, embora eu estivesse configurando o cabeçalho content-type corretamente. No entanto, mudar o código para o trecho acima "apenas faz" funciona magicamente

@ FrankHu-MSFT

Este problema ainda se apresenta ao hospedar o arquivo nas páginas do GitHub:

Como não há controle sobre o tipo de conteúdo usado pelas páginas do GitHub - qual é a solução para isso, dado que o usuário final não tem controle sobre as páginas do GitHub e o tipo de conteúdo configurado para arquivos.

A verificação do domínio do editor falhou. O arquivo JSON localizado em www.mydomain.com/.well-known/microsoft-identity-association.json tem um comprimento de conteúdo que não está definido ou é inválido. [E / SIR]

Baixe fresco do Azure e coloque em meu domínio, mas ainda falhou. alguma atualização disso?

Tenho o mesmo problema aqui. Postman e Chome indicam que o tipo de conteúdo é "application / json". Tentei criar um novo usuário no portal como você sugeriu, mas isso não corrigiu o problema.
Meu arquivo está hospedado em um servidor Apache.

@neobie , por acaso você resolveu seu problema?

Estou recebendo o mesmo erro de @abraunegg ao hospedar uma página nas páginas do GitHub com domínio personalizado.

Quando copio e colo o link a seguir, posso ver o JSON, então sei que está lá:

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

É apenas um aplicativo de página única HTML/CSS/JS simples, sem back-end de Node ou algo parecido.

_ (observação: eu tive que adicionar um arquivo .nojekyll à raiz do projeto para tornar o arquivo dentro da pasta .well-known acessível via url, de acordo com este post )

Editar:

Há uma discussão relacionada aqui:

https://stackoverflow.com/a/33619500

quais referências:

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

e parece que .json arquivo está sendo retornado com o tipo correto, então parece que é um problema do Azure e não um problema de páginas do GitHub:

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

@oshihirii , @veler , @neobie
Apenas para adicionar a isso: https://docs.microsoft.com/en-us/answers/questions/13291/publisher-domain-verification-fails-because-verifi.html?childToView=14181#comment -14181

Eu tentei resolver isso em 3 áreas diferentes conforme acima ... todas as pessoas parecem não estar interessadas em corrigir esse problema.

obrigado pela atualização @abraunegg , sim, posso ver que você e outros foram muito meticulosos na pesquisa do problema e na articulação de todos os pontos, espero que algo seja feito em breve.

Eu pensei ... em verificar o domínio de outra forma:

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

O que fiz foi apenas completar as duas primeiras etapas, ou seja, adicionar um registro de texto ao domínio e verificar.

Eu _não_ continuei adicionando mais registros para e-mail etc (porque não preciso dessa configuração).

E então, quando voltei para a página Branding do aplicativo e cliquei em Update Domain , o domínio estava lá na lista de Domínios verificados:

Isenção de responsabilidade: não tenho ideia se isso criará algumas consequências não intencionais / indesejadas, mas pelo menos eu poderia verificar o domínio e selecioná-lo.

@oshihirii
Esse processo só funciona se você for o proprietário do domínio e puder adicionar um registro TXT. Se você estiver hospedando o JSON de verificação no github - por meio das páginas do github ... você não pode seguir esse processo ...

O problema é claro, a solução é clara - o MS precisa atualizar a validação para ignorar o conjunto de caracteres se estiver definido .. muito fácil de fazer e corrigir.

@abraunegg - ah, desculpe, entendi, esqueci que você não tinha um domínio personalizado para ele (tenho, mas estou hospedando nas páginas do GitHub também). sim, acho que sua conclusão parece correta.

(caso alguém precise, e tenho certeza de que existem centenas de outros concorrentes, namesilo.com tem registro de domínio barato (com gerenciamento de DNS) ou você pode usar um registrador de domínio mais básico e, em seguida, cloudflare (para adicionar registros de texto etc)) .

@ FrankHu-MSFT
Então ... a pergunta voltou para você ... quando a Microsoft corrigirá esse problema?

Começamos a ver isso também em algumas de nossas assinaturas do Azure. A verificação de domínios da mesma forma que fizemos nos últimos anos não funciona mais, com o erro:

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]

Para referência, essa mesma abordagem funcionou por muito tempo. Apenas recentemente, quando precisamos verificar outro conjunto de aplicativos, ele começou a falhar com a mensagem acima. De fato, parece que o problema é com o Azure ou alguma alteração no funcionamento da verificação.

@ Mike-Ubezzi-MSFT
Podemos, por favor, obter alguma tração aqui para corrigir esse problema?

@abraunegg Este canal de documentação é mais adequado para levantar questões com a documentação. Se houver um problema específico com o documento, abra um novo e irei redirecioná-lo para a equipe de engenharia de identidade e segurança para tratar da documentação. Se você estiver enfrentando um problema com o produto, crie uma solicitação de suporte . O problema original levantado aqui foi resolvido e parece que há um segundo problema que não é específico da documentação e abrir uma solicitação de suporte é a ação apropriada a ser tomada.
Eu sou o recurso de plantão esta semana e minha função é fornecer uma resposta inicial e redirecionar o problema para a equipe correta. Se a funcionalidade do produto não estiver funcionando conforme o esperado, uma solicitação de suporte é o canal mais eficiente para resolver o problema. Se a documentação não estiver funcionando, recomendo abrir um novo fascículo e podemos trabalhar com a equipe de conteúdo para atualizar a documentação. Se você abrir um novo problema, certifique-se de apontar que as etapas detalhadas na documentação não estão resultando na funcionalidade declarada e incluem detalhes sobre sua implementação, sem quaisquer informações confidenciais. Agradeço sua compreensão.

Infelizmente, a solução proposta conforme articulada aqui https://github.com/MicrosoftDocs/azure-docs/issues/39665#issuecomment -538104258 é ineficaz neste ponto. Isso pode ser o resultado de outras alterações de back-end no sistema de validação do lado da Microsoft, mas, neste ponto, o fechamento do tíquete é inapropriado. Encaminhei os detalhes do cabeçalho para @ FrankHu-MSFT conforme solicitado no segmento de documentação relacionado e aguardo o acompanhamento.

Estou perplexo porque esse bug não foi corrigido. charset é uma parte do cabeçalho http na Internet. Você testou isso? A maioria das pessoas não consegue remover o cabeçalho charset de seus recursos. Por favor, demita o estagiário que escreveu e testou esse pedaço de merda.

É o modo de operação padrão "não totalmente compatível" da Microsoft mais uma vez. Apenas conserte, ok? Por que o evento se preocupa com o cabeçalho? Não há soluções alternativas simples e um bug claro.

Para mim, o código de erro foi IL2U4. Eu consertei indo para IIS, Tipos de MIME e alterando o tipo de .JSON para "application / json". É ridículo como as mensagens de erro da Microsoft são ruins. E, em qualquer caso, por que o tipo MIME importa? Os programadores da Microsoft são realmente incompetentes, eu vi isso de milhares de maneiras diferentes ao longo das décadas.

Eu tenho o mesmo problema ... este é um bug, sem ifs e ou buts sobre isso. É ridículo a quantidade de tempo que os desenvolvedores de aplicativos gastam depurando, pesquisando na Internet e tentando modificar os principais padrões aceitos para cumprir com essa restrição ridícula. A qualificação nem faz sentido.

Ecoando um comentário que vi em outro lugar, certamente as únicas verificações necessárias são:

1. O arquivo json existe no local adequado?
2. Ele contém o ID do aplicativo esperado?

O conjunto de caracteres não deve importar. . Corrija este bug, por favor.

Visto que este problema foi encerrado _e_ o problema original não está relacionado aos comentários que o restante de nós está fazendo, criei um novo problema aqui .