The following forum(s) have migrated to Microsoft Q&A (Preview): Azure Active Directory!
Visit Microsoft Q&A (Preview) to post new questions.

Learn More

 locked
Publisher Domain verification fails because "The JSON file located at {publisher_domain}/.well-known/microsoft-identity-association.json has a content length that is not set or otherwise invalid. [z6jyL]" RRS feed

  • Question

  • I'm trying to get my Python Flask app verified but keep getting this error. 
    I cannot make this "content-length" being returned by Flask. 

    Did anyone run into the same issue and found a solution? 
    Tuesday, October 1, 2019 3:42 PM

Answers

  • After more research and some time spent between different technical supports, I finally found a solution to validate our app. I'll explain it here in case it could be useful to someone.

    Cause of the issue

    The validation process proposed by Microsoft Azure AD was emitting a GET request to an endpoint on our server and expecting an 'aplication/json' response with the proper 'content-lenght' header.

    But our server is using the HTTP 1.1 protocol and

    For version 1.1 of the HTTP protocol, the chunked transfer mechanism is considered to be always acceptable, even if not listed in the TE request header field, and when used with other transfer mechanisms, should always be applied last to the transferred data and never more than one time. (Source: Wikipedia)

    And

    A sender MUST NOT send a Content-Length header field in any message that contains a Transfer-Encoding header field.
    (Source: RFC)

    It appears that the verification process does not complies with the HTTP 1.1 protocol.

    Solution

    The solution is finally quite simple: use an alternative domain validation procedure

    On Azure AD, I was able to valide our domain using a TXT record on our DN, as described in Microsoft documentation

    I hope this will help other people stuck with app domain validation.

    Wednesday, November 13, 2019 6:55 PM

All replies

  • Hello SeraphinAntEater, 

    You should be able to modify the flask response field and change the headers for the content-length. 

    Something along the lines of : 

    from flask import Response
    response = Response()
    response.headers.add('content-length', str(os.path.getsize(FILE_LOCATION)))

    for more information on this see the docs here : https://flask.palletsprojects.com/en/1.1.x/api/#response-objects

    https://palletsprojects.com/p/werkzeug/#werkzeug.Headers

    Please let me know if you have anymore questions in regards to this.

    Wednesday, October 2, 2019 12:11 AM
    Moderator
  • Hello,

    Thank you for your answer. I tried this and it's working locally but not when my app is running on Google Cloud App Engine. It looks like they're filtering some headers like 'content-length'.

    Is there any other way to verify our app?

    Wednesday, October 9, 2019 6:13 PM
  • I just realised that the content-length header is filtered because the content is encoded. 

    Are-you sending any Accept-Encoding header in the GET request? 
    Wednesday, October 9, 2019 9:25 PM
  • Hey SeraphinAntEater, 

    Yes the accept-enconding: application/json header is sent. 


    Tuesday, October 15, 2019 6:49 PM
    Moderator
  • Hey Frank, 

    Thanks for the response. I will see with google why they filter this header. 
    Tuesday, October 15, 2019 11:01 PM
  • Hi Frank, 

    I took the time to check why the app was still not working and I noticed that "application/json" is not a valid value for the "accept-encoding" header. 
    https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-Encoding

    A
    s this request is happening through HTTPS, the message is encoded and the content-length header is stripped. Don't you think it could be an issue at Microsoft side, expecting this header over https ? 
    Friday, October 18, 2019 3:40 PM
  • This is working for many customers, so I am doubtful that there is an issue from Microsoft server side in regards to the domain verification process. 

    It might be unique to the google cloud app engine compatibility with the domain verification, although I have never seen this issue occur before for any other customers.

    If you're still having an issue here, please email AzCommunity[at]microsoft[dot]com and I can enable a one time free support ticket. Please provide your Azure Subscription GUID and a reference to this thread. And hopefully we can get you on the right path again soon. 

    Please see : https://blogs.msdn.microsoft.com/mschray/2016/03/18/getting-your-azure-subscription-guid-new-portal/

    On how to get a subscription GUID.

    In addition to that once you are able to resolve your issue with the support engineer, please post your response on this thread so that future readers will be able to benefit from your solution. 

     Please remember to mark one of the responses as answer if your question has been answered. If not please let us know if there are anymore questions. Thanks
    Tuesday, October 22, 2019 2:01 AM
    Moderator
  • Just checking to see if you were able to get your question resolved. If so, please remember to mark as answer so that others in the community with similar questions can more easily find a resolution.

    Please take a moment to "Mark as Answer" and/or "Vote as Helpful" wherever applicable. Thanks!

    Friday, November 1, 2019 9:37 PM
    Moderator
  • Hello, 

    Thanks for following up. My issue is still not resolved. I'm contacting MS support as suggested by Frank. 
    Monday, November 4, 2019 4:28 PM
  • After more research and some time spent between different technical supports, I finally found a solution to validate our app. I'll explain it here in case it could be useful to someone.

    Cause of the issue

    The validation process proposed by Microsoft Azure AD was emitting a GET request to an endpoint on our server and expecting an 'aplication/json' response with the proper 'content-lenght' header.

    But our server is using the HTTP 1.1 protocol and

    For version 1.1 of the HTTP protocol, the chunked transfer mechanism is considered to be always acceptable, even if not listed in the TE request header field, and when used with other transfer mechanisms, should always be applied last to the transferred data and never more than one time. (Source: Wikipedia)

    And

    A sender MUST NOT send a Content-Length header field in any message that contains a Transfer-Encoding header field.
    (Source: RFC)

    It appears that the verification process does not complies with the HTTP 1.1 protocol.

    Solution

    The solution is finally quite simple: use an alternative domain validation procedure

    On Azure AD, I was able to valide our domain using a TXT record on our DN, as described in Microsoft documentation

    I hope this will help other people stuck with app domain validation.

    Wednesday, November 13, 2019 6:55 PM