Allow hosting any files through sharepoint/gdrive

[synox]

Let's allow more file formats to ingested from sharepoint/gdrive or slack bot.

Need
Our customer has .xlsm files they want to provide for download on their website. Currently, the content-pipeline returns 404, because it tries to serve it as JSON.

Tried
As a workaround, we tried to serve it as a zip file. But currently zip files can not be pushed to the content pipeline. Also slack bot does not accept the zip file.

Workaround

• As a workaround we added the files to the git repo, but that's not great. Content does not belong there.
• If the customer has a DAM, they might be able to publish it there and link to it.

[tripodsan]

xlsm files are potentially dangerous as they contain scripts that can harm the users computer. currently we are reluctant to offer such file for downloading. the customer needs to use a 3rd party filestorage provider.

[synox]

I understand the concerns for xlsm. But ZIP files are very common, and hosting them externally seems cumbersome and not a great experience.

[dkuntze]

are we offering a third party storage party suggestion?

[trieloff]

I'd go with the one that's included in your cloud provider:

• AWS: S3
• Cloudflare: R2
• Google Cloud Storage
• Azure Blob Storage

[solaris007]

SharePoint is also a valid storage, many customers having their content and PDF assets there already. hlxsites SP org should at least allow creating public links on files.

[synox]

When the customers eventually move to their own Sharepoint org, these shared links will become invalid. And updating all the links will be cumbersome.

[helms-charity]

I have a customer asking for this. All their ebook pages have a companion set of files to be downloaded via a zip file.

[andrewmkhoury]

For internal product we would like to make the site theme-able / brandable by administrators.
To accomplish this we would need to allow the customer to upload font files (woff, woff2, otf, etc) to a secured folder in sharepoint.

[davidnuescheler]

we don't see Franklin as a passive hosting platform for arbitrary files, but really only want to intelligently serve content and content formats that are used by a vast majority of public websites.

there are usually files that are attached to an authoring lifecycle (preview, publish) and files that are attached to dev lifecycle (branch, PR, merge) and those should live in the corresponding container. everything that comes in from authoring needs to be sanitized from a a security standpoint as we don't see a path to where an author understands (web) security implications, which is why the list of file formats that we accept from authors is very narrow and we actively manipulate those files where needed to remove potential security issues before ingesting them into the Franklin contentbus.
as far as things coming in from web devs we assume that they understand web security, which is why we are a lot more lenient with allowing a broad set of file formats and content types coming in through that route.

a good way to think about this is to think of authoring ingested file formats to be a tightly managed allow list, while dev ingested content to be a permissive deny list.

so we probably want to have individual discussions per file type that you would like to propose to be added, and discuss if there are ways to either support that with the current infra (eg. we had usecases that needed csv or ics that were well served with the existing infrastructure) or if third party hosting (eg. AEM Assets, adobe fonts, brightcove, etc.) is a good solution, or if we feel that file type is pervasive enough across many projects for authors that we would like to add it to the supported list of file types.

eg. for the above request for fonts for theming, i think https://fonts.adobe.com/ is the right way to go, or the customers actual production www website.

[andrewmkhoury]

Thanks for the clarification David. What you described in your example [1] is exactly the approach we already implemented.

[1]

eg. for the above request for fonts for theming, i think https://fonts.adobe.com/ is the right way to go, or the customers actual production www website.