locked
WAP/ADFS 3.0: 307 redirect response to SOAP POST request is against specs and therefor fails on Firefox RRS feed

  • Question

  • Hi,

    we have a silverlight in-browser application secured by Web Application Proxy. In the application we use Reporting Services WebService to list folder items and render reports. Reporting Services is published seperately in the WebApplication Proxy. But when the application (after initially being authenticated with ADFS and using cookies for SSO) sends a SOAP Post request to the ReportingServices2005.asmx, the Web Application Proxy sends a 307 redirect with the location of the ADFS to authenticate. This would be no problem since we are already authenticated and due to the MSIAuth-Cookie the ADFS would only issue a new token for this WAP app. But Firefox browsers do not perform the redirect, what is the expected behaviour according to Http-Specs because it is a POST and not a GET operation. IE does (thus violating Http specs), but our app needs to run on Firefox, also. Please advise

    P.S.: we'd be thankful for receiving some answers instead of being pushed (=moved) around as was the case for every other question regarding ADFS/WAP/WebServices. It seems that no one feels responsible for these issues and only wants to get rid of them ;-(

    Friday, March 18, 2016 8:58 AM

All replies

  • Let's dig into it then :) I am not aware of this scenario. Therefore, I'd like more details if you don't mind (version of the browsers, export of the WAP publication etc...). And ideally, a fiddler trace for working and non working scenario (note that fiddler traces do contains clear text passwords, so please sanitize them before sharing).


    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Friday, March 18, 2016 1:40 PM
  • Well, it's both the latest browser versions. And the fiddler difference is: IE performs redirect to ADFS after receiving 307, but FireFox does not. Firefox receives the 307, that's it. No more http-traffic after this. As explained, Fiddler is doing right according to 307-specs along with POST, but ReportingServices-WebService can only be called with POST?
    Friday, March 18, 2016 3:49 PM
  • So what are the cases?

    1. FireFox > SQL Reports = OK
    2. IE > SQL Reports = OK
    3. FireFox > WAP > SQL Reports = OK
    4. IE > WAP > SQL Reports  = NOK

    Is that correct?

    The reasons why I was looking for Fiddler traces isn't only to see what the client is doing in reaction of the WAP server is sending, but what the client is actually sending in the first place (including headers, URLs, cookies etc...).


    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Friday, March 18, 2016 4:01 PM
  • 1. and 2. true, 3. and 4. vice versa: IE ignores "don't automatically redirect POST after 307 response" and does redirect, FireFox obeys the law and does not redirect.

    Request:

    POST https://devsk.software4you.com/reportserver/reportservice2005.asmx HTTP/1.1
    Accept: */*
    Referer: https://devsk.software4you.com/4PlanWeb2/Software4You.S4Plan.Web/ClientBin/S4Plan.xap?version=vv3.3.1.0
    Accept-Language: de-DE
    Content-Length: 351
    Content-Type: text/xml; charset=utf-8
    SOAPAction: "http://schemas.microsoft.com/sqlserver/2005/06/30/reporting/reportingservices/ListChildren"
    Accept-Encoding: gzip, deflate
    User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; rv:11.0) like Gecko
    Host: devsk.software4you.com
    DNT: 1
    Connection: Keep-Alive
    Cache-Control: no-cache

    <s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"><s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"><ListChildren xmlns="http://schemas.microsoft.com/sqlserver/2005/06/30/reporting/reportingservices"><Item>/LR</Item><Recursive>true</Recursive></ListChildren></s:Body></s:Envelope>

    Response:

    HTTP/1.1 307 Temporary Redirect
    Content-Length: 0
    Location: https://fs.software4you.com/adfs/ls?version=1.0&action=signin&realm=urn%3AAppProxy%3Acom&appRealm=c47dc664-96c6-e511-80bc-00155d322e2e&returnUrl=https%3A%2F%2Fdevsk.software4you.com%2Freportserver%2Freportservice2005.asmx&client-request-id=EAD6C776-7B60-0000-2826-D7EA607BD101
    Server: Microsoft-HTTPAPI/2.0
    Date: Tue, 22 Mar 2016 12:50:35 GMT

    Tuesday, March 22, 2016 2:29 PM
  • When you say it does not work with Firefox, are you at least prompted to know whether or not you want to be redirected? The RFC2616 states:

    If the 307 status code is received in response to a request other   than GET or HEAD, the user agent MUST NOT automatically redirect the   request unless it can be confirmed by the user, since this might   change the conditions under which the request was issued.

    Something like:


    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.


    Tuesday, March 22, 2016 4:07 PM
  • No, there is no prompt. But we call a web service from within silverlight code, i don't know if a prompt would be displayed by the browser in this case?
    Tuesday, March 22, 2016 4:22 PM
  • Good point. I am not familiar with Silverlight coding either :) I do not know.

    And we assume that sending a 303 instead of a 307 would be interpreted better in your case (since 32 doesn't prompt and is allowing change of method)? Can you test that? Configure a website to redirect to a random URL using a 302 and see if your code runs fine?


    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.


    Tuesday, March 22, 2016 4:29 PM