Forum Discussion
SharePoint Authentication from C# Application
- May 03, 2019
I have this working now, and the issue seems to have been related to the URL used when you get your client context object. Our SharePoint implementation has multiple levels of sites within it. We have separate sites for every customer, and then a top level site. I was attempting to get a file from a library under a customer site, and I had been using a URL that corresponded to the customer site. Once I changed the code to use the top level site (literally just the domain name) for the client context, the popup browser started getting the FedAuth cookie and things started working. So either I don't properly understand how our SharePoint is implemented, or the authentication method is extremely sensitive to the URL you use to get the cookies. The absolute URL to the file I was attempting to copy down looks something like this:
https://mycompany.sharepoint.com/customers/theclientname/797%20Project%20Name/In%20Process%20Templates/standard.xml
This URL is a valid site:
https://mycompany.sharepoint.com/customers/theclientname
But when I used that URL with AuthenticationManager.GetWebLoginClientContext(), it failed. Switching it to use:
https://mycompany.sharepoint.com
to get the client context fixed the problem. Now, if permissions were different at these different levels, I suspect this would have failed - it would have gotten a valid client context, but suspect I could still have gotten a permissions error when trying to use OpenBinaryStream() on my file object.
This was a frustrating journey, and I was disappointed to not get any feedback from anyone else. Apparently my limited understanding of SharePoint and how to integrate to it is not as common as I thought it might be.
So I dug into this a little deeper, and discovered that it is happening because the code behind the GetWebLoginClientContext() method is looking at the cookies, specifically for cookies that have "FedAuth" or "EdgeAccessCookie" in their names. If those cookies are found, and only if they are found, the form automatically closes. I created my own implementation of the method so I could step through the code, and discovered that since it is not finding those cookies, it is not closing the form. So the real issue is that those cookies are not present in the HTTP Response. At least I've got a better lead now.
More research results...
Using Fiddler, I can see that the FedAuth cookie DOES come back in the response, but the part of GetWebLoginClientContext that retrieves the cookies is not seeing that cookie.
Looking into how the cookie retrieval process works I see that the code that retrieves the cookies is using InternetGetCookieEx() implemented in wininet.dll. That function is returning a string that does NOT contain the FedAuth cookie.
I'm not quite sure where to go with this next, unless there is a different way to retrieve the cookies.