Forum Discussion
SharePoint Authentication from C# Application
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.
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.
dougb628 I'm glad you continued to add comments here as I was having the same issues. Someone reported this as a bug in December 2019, however it is not fixed yet, https://github.com/pnp/PnP-Sites-Core/issues/2508.
Though we all are seeing the same behavior, the underlying causes are different. The reporter of the bug found the error when using a SharePoint Add in and his work around was to add another cookie to the list of cookies it attempted to find. Your issue was that it wasn't providing a cookie that was in fact there. My issue is that it freezes on the browser.Navigated call. I get pop-up browser window, but when debugging it never drops into the code under browser.Navigated. I have no fix at the moment. This behavior is intermittent, it will work once and then not work again until my app is closed and reopened. No exception occur and even when I step into the browser.Navigated call, it actually looks like it just skips over the call and goes to the next line.
kirstenray You not alone :(.
In a meantime did you find something? I am currently debugging and like you said sometimes it works and sometimes not.
Mainly, I noticed that if in main site where I am connected if I have subsites and try to drilldown in some of subsites that, usually, does not work.
Well, it looks like that this is not connected to subsites but to how many clicks I had.
For example, it looks like that after 3-4 clicks in short period it is stopping to work and shows only empty browser window.
It is weird as sometimes if I leave it for some period it will connect to selected URL and all will work until next click :(.
kirstenrayI hope this gets resolved soon, but I actually haven't really done much with this once I got it working by just using the domain name. In our case, all of the users of this C# application have essentially the exact same access all over our SharePoint, so I think that is why it started working for me. Frankly, I still don't know that much about integrating to SharePoint, and I think it's pretty crazy that you have to launch a browser to authenticate. Granted, it is a web application, but the authentication from the OS is much more streamlined. I can open a Windows File Explorer window, and type in a SharePoint address in the address bar, and it authenticates completely transparently, probably using Kerberos or something - I don't know. Why can't my C# application authenticate in a similar manner?
