none
downloading Sharepoint files via the IAG RRS feed

  • Question

  • Hi,

    I'm new to the IAG and looking for some help in understanding what is going on behind the scenes.

    We have a Sharepoint 2007 application that sits behind a proxy server (ISA) with an IAG 2007 server which authenticates a user session. 

    I have inherited some C# code wrapped up in an ActiveX component that sits on the client and does the following:
    1) downloads one or more documents from a sharepoint document list onto the client (root of C: drive) using the httpwebrequest and webclient objects
    2) prints each document out as a batch

    i.e. it is a bulk printer for Sharepoint docs.

    Without the IAG in place and going on to a Sharepoint application there is no problem downloading word binary files etc. However, with the IAG in place the files output have the appropriate extension e.g. .doc, .xls etc but the content is text/html and not binary and there is a whole bunch of javascript code with function names such as whlGetDomainName, whlGetCookieName, whlFunction. Below this is an html frame element with a src attribute referencing the document that is to be downloaded/printed. I've pasted the content of the "word" doc below this post.

    Obviously, this is no good to me and what I was expecting was the actual physical documents to be downloaded off the Sharepoint server ready for the print routine to do it's job.

    Is this behaviour by design and if so is there a switch/configuration I can make so that I can get the client component to download the actual physical files?

    I'm also looking at optimizing the code. At the moment for example:
    1) a document is requested when a user clicks on a javascript print link on the Sharepoint app. This instantiates the client component and sends a request for the documents. The response to this is the text/html IAG login page and the cookies are stored in a cookiecontainer object
    2) the response content is parsed and the username and password along with other required name/value pairs are posted to the target parsed form the content (validate.asp - this has a different whalecomblahblah string in the url) using the cookies in the cookiecontainer
    3) a webclient then downloads the file with the output being the text/html file below this post using the cookie returned in the previous response.

    My question here is does the IAG authenticate using the cookies returned in the request and in theory could I pass the original cookies from the Sharepoint document list page with the print link into the client component so that any further requests from the component are authenticated against the IAG? This seems to me like hijacking a cookie and trying to defeat the whole point of the IAG.

    Any help appreciated.

    Thanks,
               Anant

     

    ----------------------------------------------------------------------------------------------------------------------------------------

    <html>

    <script>

    //warn the user that sharepoint integartion with office is disabled

    if(("True" != "True") && ("" == "TRUE"))

    alert("When accessing more than one SharePoint site, working with Office documents is only enabled from the first site you opened. In order to work with Office documents from this site, log out of the portal and re-access the site.");

    var g_inter = null;

    function Get_Cookie(name) {

    var start = document.cookie.indexOf(name+"=");

    var len = start+name.length+1;

    if ((!start) && (name != document.cookie.substring(0,name.length))) return null;

    if (start == -1) return null;

    var end = document.cookie.indexOf(";",len);

    if (end == -1) end = document.cookie.length;

    return unescape(document.cookie.substring(len,end));

    }

    function Set_Cookie(name,value,expires,path,domain,secure) {

    document.cookie = name + "=" +escape(value) +

    ( (expires) ? ";expires=" + expires.toGMTString() : "") +

    ( (path) ? ";path=" + path : "") +

    ( (domain) ? ";domain=" + domain : "") +

    ( (secure) ? ";secure" : "");

    }

    function whlGetDomainName() {

    var index1 = location.host.indexOf(".");

    domainName = location.host.substr(index1);

    return domainName;

    }

    function whlGetCookieName(isSecure) {

    var cookiePre = "NLSession";

    isSecure ? cookiePre = cookiePre + "S" : cookiePre = cookiePre + "C";

    var aCookie = document.cookie.split("; ");

    for (var i=0; i < aCookie.length; i++) {

    var aCrumb = aCookie[i].split("=");

    if (aCrumb[0].indexOf(cookiePre) != -1)

    return aCrumb[0];

    }

    return null;

    //return "NLSessionCdols4";

    }

    function interval() {

    if (whlFunction() == true)

    setInterval("whlFunction()",10 * 1000);

    return true;

    /* This is how it worked before we forced the cookie to start on load.

    g_inter = setInterval("isPersNeeded()",500); */

    }

    function isPersNeeded() {

    var coo = Get_Cookie("NeedPersCookie");

    if (coo == "1") {

    if (g_inter != null)

    clearInterval(g_inter);

    g_inter = null;

    whlFunction();

    setInterval("whlFunction()",10 * 1000);

    }

    }

    function whlFunction() {

    /*

    We force the cookie to be created onload.

    if (this.document.getElementById("SharePointFrame").name == "AWRunning_FALSE" || this.document.getElementById("SharePointFrame").isOffSp1 == "False")

    return false; */

    var isSecureProtocol = window.location.protocol.indexOf("https:");

    if (isSecureProtocol == 0)

    isSecureProtocol = "secure";

    else

    isSecureProtocol = null;

    var g_cookieName = whlGetCookieName(isSecureProtocol);

    var today = new Date();

    var expiry = new Date(today.getTime() + 15 * 1000); // 15 seconds

    var g_cookie = Get_Cookie(g_cookieName);

    var g_domainName = whlGetDomainName();

    Set_Cookie(g_cookieName,g_cookie,expiry,"/",g_domainName,isSecureProtocol);

    return true;

    /* This is how it worked before we forced the cookie to start on load.

    Set_Cookie("NeedPersCookie","1",null,"/",null,null); */

    }

    function closeIt() {

    //alert the user only once , when leaving the Portal

    if ("TRUE" == "TRUE")

    {

    try {

    if (top.window.frames(0).whlLogoffEvent)

    for(i=0;i<1;i++);

    else

    event.returnValue = "Unsaved changes to documents opened within SharePoint will be lost,";

    }

    catch (e) {

    event.returnValue = "Unsaved changes to documents opened within SharePoint will be lost,";

    }

    }

    }

    function deleteCookie() {

    /*

    We force the cookie to be created onload.

    if (this.document.getElementById("SharePointFrame").name == "AWRunning_FALSE" || this.document.getElementById("SharePointFrame").isOffSp1 == "False")

    return false;*/

    var isSecureProtocol = window.location.protocol.indexOf("https:");

    if (isSecureProtocol == 0)

    isSecureProtocol = "secure";

    else

    isSecureProtocol = null;

    var cookieName = whlGetCookieName(isSecureProtocol);

    var domainName = whlGetDomainName();

    var today = new Date();

    var expiry = new Date(today.getTime() - 24 * 60 * 60 * 1000); // 1 day

    Set_Cookie(cookieName,"0",expiry,"/",domainName,null);

    }

    </script>

    <head>

    <TITLE>SharePoint Portal Server</TITLE>

    <frameset rows="100%" FRAMEBORDER="NO" BORDER="0" FRAMESPACING="0" onunload="deleteCookie()" onbeforeunload="closeIt()" onload="interval()">

    <!-- <frame name="AWRunning_TRUE" src="/InternalSite/Images/logo.gif"> -->

    <frame id="SharePointFrame" name="AWRunning_TRUE" src="http://iag.contoso.com/whalecoma6c1fd894dbb82fde0/whalecom0/Shared Documents/Chapter 2 - Deploying ISA Server.doc" isOffSp1="True">

    </frameset>

    <noframes>

    </head>

    <body>

    <br></noframes>

    </body>

    </html>

     

     

    Tuesday, July 14, 2009 11:00 AM

Answers

  • Sorry for the late response and thanks for your response Ben.

    It turned out that the problem was that the client control was not using the cookies from the container page in any http requests being made from within the control. The IAG sees this as being a new unauthenticated session and hence the problems. 

    I have modified the code to pass in the cookie from the container page to use in subsequent http requests within the component and my problems went away.

    Anant
    • Marked as answer by bodgkin Thursday, July 23, 2009 3:08 PM
    Thursday, July 23, 2009 3:07 PM

All replies

  • The stream you are receiving is the IAG framed page, as your application does not know how to interact with IAG and parse the frameset to request the "real" document URL. If you have an option to modify the source and recompile it, you might have luck in modifying it to parse the frameset, retreive the document's real location (in this case, <frame id="SharePointFrame" name="AWRunning_TRUE" src="http://iag.contoso.com/whalecoma6c1fd894dbb82fde0/whalecom0/Shared Documents/Chapter 2 - Deploying ISA Server.doc" isOffSp1="True"> ) and download it.

    If you do not, then your other option is to publish SharePoint as a separate trunk, with it set as the initial application and the option to "use toolbar" off. That will display the portal as-is, without the frames, and the external code should be able to parse it correctly. It's the most transparent way to publish SharePoint, but it will require you to dedicate an IP to it, with all the standard infrastructure (public DNS record, Certificate etc, AAM configuration etc)

    Ben Ari
    Microsoft CSS IAG Support
    Sammamish, WA
    • Marked as answer by Erez Benari Wednesday, July 15, 2009 8:02 PM
    • Unmarked as answer by bodgkin Thursday, July 23, 2009 3:06 PM
    Wednesday, July 15, 2009 8:02 PM
  • Sorry for the late response and thanks for your response Ben.

    It turned out that the problem was that the client control was not using the cookies from the container page in any http requests being made from within the control. The IAG sees this as being a new unauthenticated session and hence the problems. 

    I have modified the code to pass in the cookie from the container page to use in subsequent http requests within the component and my problems went away.

    Anant
    • Marked as answer by bodgkin Thursday, July 23, 2009 3:08 PM
    Thursday, July 23, 2009 3:07 PM