The Best Way to Surface SharePoint Data from Microsoft 365 in a Public Site

Microsoft 365 in a Public Site

I recently created a proof of concept web application for a personal funding web site for a prospective project.  The concept is a site in which users can create a personal profile, tell their story, and create a wish list of products, selecting from among a set of products configured by the site owner.  As a key design goal, I wanted all of the data to be stored in SharePoint.  My point is that I’d like to either be concerned with SharePoint, or I’d like to be concerned with a database, but not both.

The screen snap below illustrates how a user profile appears on the site.


Key points of the design:

  • The site is configured to support Live Id authentication.
    • Conveniently, MVC applications, by default, include infrastructure to support authentication via Live Id, Facebook, Twitter, and Google.  Some configuration, of course, is required.
    • Users who access the data stored in the SharePoint site do not need an account or direct access to the data.
  • By default, the storage provider for MVC applications stores user profiles and roles in a database.  However, I wanted to avoid databases as part of my application and go all in with SharePoint.
    • For that reason, I implemented a custom user store by implementing IUserStore and IUser, and of course, the necessary plumbing for the implementation to speak with SharePoint.
    • I used this blog post as a guide for understanding the interfaces I needed to implement for a custom storage provider.
  •  For this application, there is one custom list and one picture library in SharePoint.
    • The custom list stores data necessary to support the custom IUser and IUserStore implementation, and it also stores the user’s wish list as a multi-select lookup.
    • The picture library and associated metadata is used to store the list of products from which a user may select.
  • Access to SharePoint is provided via a service account, using Microsoft 365 credentials that are stored in the web.config.
    • If you use a user account for this purpose, like me, you’ll need to be sure to set the password expiration for this account to never expire, or you will need to be aware of the password expiration policy and plan accordingly.
    • I could have chosen to access the SharePoint data using “app only calls” from within the context of a SharePoint application.  In this case, the client id and client secret are also stored in the web.config, and the client secret expires annually.
    • In my view, using a user account for this purpose is the simpler path vs. using an application principal.  Using a user account will cost you an annual license, $96 per year last I checked, but I view the simplicity of the approach tiling my decision just slightly in favor of using a user account.  If you change your mind, and I may, it’s not difficult to switch over to using an application principal since they both use the same API to access SharePoint.

By storing this data in SharePoint, I can take advantage of SharePoint out-of-the-box features such as search, list views, alerts, and more, for users who access this data natively in the SharePoint user interface.  Further, I can include user activity from my public site in workflows and processes that involve users who are internal to our company.  With this design, I am projecting SharePoint data out into the public site, and users in the public site are able to project their activity into SharePoint.

Have you been thinking about surfacing data from SharePoint in your MVC applications?  Let’s talk about it in the comment section below.

Eric BowdenThe Best Way to Surface SharePoint Data from Microsoft 365 in a Public Site

Join the conversation

This site uses Akismet to reduce spam. Learn how your comment data is processed.