none
Sending contents to windows authenticated service results in an error - "Content option is only supported when connecting anonymously." RRS feed

  • Question

  • Error results when trying to send JSON content to a service which is internally hosted and requires windows authentication.

    Here is the sample code :

    let
       Content1 = "{""query"":....."},
        Source1 = Web.Contents("http://MyWindowsAuthenTicatedService:####/" ,[Content=Text.ToBinary(Content1)])
    in
        Source1

    Here is exact text from the error:

    [DataSource.Error] Web.Contents with the Content option is only supported when connecting anonymously.
    

    BTW, I tried configuring the Privacy and "Fast Combine" options and that does not work either

    Thanks for your help !

    Tuesday, October 28, 2014 4:24 PM

Answers

  • For security reasons, we don't currently support this scenario. It would be too easy for someone to share a malicious query that uses your windows credentials to edit or delete data. We hope to have an alternate trust mechanism in place in six months or so which would make this possible. That is not, of course, a commitment :).
    Tuesday, October 28, 2014 8:04 PM

All replies

  • For security reasons, we don't currently support this scenario. It would be too easy for someone to share a malicious query that uses your windows credentials to edit or delete data. We hope to have an alternate trust mechanism in place in six months or so which would make this possible. That is not, of course, a commitment :).
    Tuesday, October 28, 2014 8:04 PM
  • Thanks Curt, for the prompt reply.

    In our case, the users are internal and so is the service which accepts the content.  Once the user is authenticated by the windows account, it reasonable to allow content.  

    Would it not be better anyway to have the restriction for anonymous access as opposed to this case where the account is already authenticated on an internal windows domain ?


    Wednesday, October 29, 2014 2:58 PM
  • Wondering if you have any updates on the timeline for a release :-)  Thanks,
    Friday, November 21, 2014 6:18 PM
  • Not yet, sorry.
    Sunday, November 23, 2014 5:31 PM
  • Any updates on the timeline for a release in the New Year ?  Thanks,
    Friday, January 9, 2015 7:21 PM
  • Hello Curt,

    Any update on the envisioned alternate trust mechanism ?

    We will be very happy to get this feature running on a Windows authentication mode.

    Thanks for your feedback.

    BR,
    BB.


    • Edited by SOS-MS Wednesday, May 11, 2016 7:27 PM
    Wednesday, May 11, 2016 7:27 PM
  • Hello,

    any plan to allow custom content / headers for authenticated  sources ?

    It does not work also for basic http  authentication, when using

    DataSourceKind=Web....

    :-(

    I fail to see the security reasons here.....

    P.

    Tuesday, October 11, 2016 12:55 PM
  • Microsoft:

    Agree with prior post (Pavel) in regard to Power BI web datasources that are protected using basic authentication over https.  In our use case, we are paging (scroll api) over Elastic Search queries.  This for each page, the ES scroll api returns a rather large scroll_id.  Subsequent requests for the next page requires passing the scroll_id.  This can be passed on the uri, however many times it can exceed the max url length.  ES also supports passing as a POST parameter, but since Web.Contents does not support POST requests with basic authentication, this presents a problem.

    Please advise if there is a recommended workaround and/or when support for this may come.

    Many thanks, David

    Tuesday, February 28, 2017 10:28 AM
  • We hope to have an alternate trust mechanism in place in six months or so which would make this possible. That is not, of course, a commitment :).

    Hi, is there any news on it?
    Or may be someone know how to workaround it?

    We facing this issue in Integration Services dataflow task PowerQuery source component. 

    Wednesday, May 29, 2019 4:01 PM
  • For security reasons, we don't currently support this scenario. It would be too easy for someone to share a malicious query that uses your windows credentials to edit or delete data. We hope to have an alternate trust mechanism in place in six months or so which would make this possible. That is not, of course, a commitment :).


    I think this is not considering many other uses. I would consider it a security issue to embed an API key into an Excel file in order for the queries to work. This would allow people to use this API key and then modify the query to the server, or otherwise share it. For domain cases, it may not be an issue because it may be safe to assume that people would not have access to the service outside of the network anyway. But for non-domain cases, this is MUCH less secure because you are saving an API key into a file for a publicly accessible service.

    Furthermore, what if a service decides to work around this POST restriction and modify their GET endpoint to allow data updates with authenticated users? It poses the same security risk, except it forces extra work for the API maintainer.

    Also, almost five years later and no update on this?

    Wednesday, July 31, 2019 4:27 AM