I am migrating a SharePoint 2007 solution to SharePoint Online (O365), and need to replicate a feature whereby some information provided in SharePoint is displayed on a public web page. The information is a SharePoint Calendar. Each time the public page is hit (20 times a week maybe) the public page uses a stored credential to read the date/time and title of the events only. It is a quick way to check the calendar without being logged in and without showing more private details like location or body of the item.
I had created an ASPX page in SharePoint that renders the view I'd like, then in the public ASP.NET page used HttpWebRequest to read the page, supplying a Credential using a stored username/password.
Again, for clarity, the user is not logged is, but sees a page with some basic facts from a SharePoint Online Calendar on an anonymous, non-SharePoint enabled, ASP.NET hosted page. So I don't think this is actually an "app", nor can I use the SharePoint Client SDK.
The code to do this was simple but returns a 403 using the new SharePoint. I am under the impression that this is due to SharePoint Online's reliance on Claims Based Authentication.WebRequest myRq = HttpWebRequest.Create(url);
myRq.Credentials = new NetworkCredential(myAcct, myPWD, myDomain);
WebResponse myRsp = myRq.GetResponse();
I need to know if there is a way to create and pass an appropriate claim using stored username password.
(Yes, I know that the password needs to be stored securely, I've simplified the code above for clarity.)
Looks like the 403 was a result of not setting the User Agent String. So now the call redirects to the interactive login page.
This article: http://msdn.microsoft.com/en-us/library/hh147177(v=office.14).aspx refers to a configuration on SharePoint online where the cookie is set to httponly.
So is all the information in my SharePoint online site locked up there and not programmatically accessible?
SharePoint Online does not allow for deploying ASP.NET artifacts such as HTTP Handlers and building apps is the only approach to deploy custom solutions to Office 365. With this I guess you will need to revise the architecture of your solution based on the App model.
Thanks for taking the time to review my post and offer your suggestion.
The ASP.NET code is deployed on another host, outside of the SharePoint environment entirely. The goal is to have this page use cached credentials of some sort to access the Calendar and display basic details only.
So my most recent approach is to use a provider hosted app to read the list and write a plain XML file. This page becomes a "Publish" step for the data, done by the person updating the calendar.
Then a different page on that same host, and here's the kicker - which is served up anonymously - can read the XML file and render something pretty.
If I get that working I'm considering putting this publish code in a remote event handler for the list, but one step at a time.
Since the anonymous page really only gets ten or twenty hits a week I'd really rather have that anonymous page read the data in real time. But I'm not seeing any mechanism to get authorized that doesn't involve a web page with two boxes and a button, meant for a human to interact with.
Thanks again for taking the time.