Publishing a SharePoint document library on a website without copying the files

What is wrong with just uploading the files to the website?

Nothing, on the first day. The problem is the second version. Publishing by export creates two copies of every document and an unwritten obligation to keep them in step, and that obligation is discharged by a person who has other work — so the website drifts behind SharePoint, silently, and nobody finds out until a customer quotes a superseded price list back at you.

• The stale-copy failure — the site serves last quarter's document because the re-upload did not happen.
• The orphan failure — a file is removed from SharePoint for a good reason and stays downloadable from the website, because removal was never part of the workflow.
• The permission failure — the website copy has no relationship to the library's permissions, so a document restricted in SharePoint is unrestricted on the web.

What is a document library, in Graph terms?

A drive, hanging off a site, containing driveItems. That single sentence explains most of the API surface: a SharePoint document library and a OneDrive folder are the same kind of object to Microsoft Graph, which is why a component that can render one can render the other with no extra work.

It also explains the addressing problem everyone hits first. A human names a library by its site URL and its display name; Graph wants a site id and a drive id. Resolving one to the other is a lookup, and it is the kind of lookup that belongs on a server where it can be cached, rather than in the browser where it becomes two extra round trips before anything renders.

How do you publish part of a library without exposing the rest?

By deciding the subset in configuration, so that everything outside it is unreachable rather than merely unlinked. Four controls do most of the work, and they compose.

• Pin the root. A folder path or folder id sets where browsing begins, and navigation cannot go above it. This is the strongest of the four, because it is a structural bound rather than a filter.
• Allow only the file types you publish. An extension allowlist hides everything else. Folders stay visible so navigation still works when only PDFs are listed.
• Decide about downloads separately from viewing. A library can be readable in the page without being distributable from it — switching downloads off is a real distinction for licensed or watermarked material.
• Page it. A large library fetched in one request is a slow page and a large payload. Page size belongs in the configuration, and a sensible cap belongs in the server.

Scope the permission as well as the view. Sites.Selected lets an administrator grant an application access to named site collections instead of every site in the tenant — but only if no broader site or file permission is also attached to the same application, because Graph permissions are additive and the most permissive one wins.

What goes wrong in practice?

• Someone assumes SharePoint permissions carry through. They do not. The application reads with its own permission, so a document with unique permissions inside a library the application can read is still readable by the application — and therefore publishable to the web. Restricting a document in SharePoint is not the same as excluding it from the page.
• Renaming the library. If the component is configured by display name, renaming the library in SharePoint breaks the resolution. Configuring by id survives a rename; configuring by name survives a site migration. Pick knowingly.
• Expecting every file type to preview in place. Images and PDFs render in a page lightbox. Office formats are best handed to Microsoft's own viewer in a new tab, because reimplementing Word rendering in a widget is not a feature, it is a project.
• Very large libraries. Sorting and searching feel instant on two hundred items and do not on twenty thousand. Narrow the root, filter the types, and let the source do the work it is good at.

What should you check before it goes live?

1. Open the page as an anonymous visitor, in a private window, and confirm every file listed is one you intended to publish.
2. Navigate upward from the pinned folder and confirm you cannot get above it.
3. Add a file to the library and reload the page. If it does not appear, something is caching that should not be.
4. Remove a file and reload. If it still appears, you have a copy somewhere.
5. Check the permission the application actually holds, and confirm that a site it was not granted returns access denied.