File System Encryption- implementing IStorageProvider

Context: .NET MVC 5 Site
I have a need to have application level encryption so that all files that end up on the file system are encrypted.

I have implemented my own IStorageProvider as per http://groupdocs.com/Community/forums/4426/implementing-istorageprovider/showthread.aspx

This is working well, and files that go through the IStorageProvider instances end up encrypted on disk.

But other related files do not. I think they are being created by the DocumentCache class.
But I don't see a way to hook into the cache generation like I can by implementing IStorageProvider by wrapping LocalFileStorage

For example, given this setup

Viewer.SetRootStoragePath("C:\viewer-cache\root\", "C:\viewer-cache\working\");
Viewer.SetStorageProvider(
new EncryptedLocalStorageProvider(root),
new EncryptedLocalStorageProvider(working));

And a call like this in my cshtml
var helper = Html.ViewerClientCode().TargetElementSelector("#doc-viewer-viewer")
.ShowDownload(false)
.ShowFolderBrowser(false)
.ShowPrint(false)
.ZoomToFitHeight(Model.ViewerOptions.ZoomToFitHeight)
.ZoomToFitWidth(Model.ViewerOptions.ZoomToFitWidth)
.ShowThumbnails(Model.ViewerOptions.ShowThumbnails)
.OpenThumbnails(Model.ViewerOptions.OpenThumbnails)
.ShowPaging(Model.ViewerOptions.ShowPaging)
.ShowViewerStyleControl(Model.ViewerOptions.ShowViewerStyleControl);
helper.Url(Url.ContentAbsolute("~/Content/Images/no-document-selected.png"))

I end up with the following files on disk


Not Encrypted
C:\viewer-cache\root\temp\FromURL\http___localhost_Content_Images_no-document-selected
C:\viewer-cache\working\Cache\temp\FromURL\http___localhost_Content_Images_no-document-selected.png\2015-07-20T20_21_33\100@150x.Pdf\page_0.jpg
C:\viewer-cache\working\Cache\temp\FromURL\http___localhost_Content_Images_no-document-selected.png\2015-07-20T20_21_33\100@852x.Pdf\page_0.jpg
C:\viewer-cache\working\Cache\temp\FromURL\http___localhost_Content_Images_no-document-selected.png\2015-07-20T20_21_33\100@x.Pdf\page_0.jpg

Encrypted
C:\viewer-cache\working\temp\FromURL\http___localhost_Content_Images_no-document-selected.png\2015-07-20T20_21_33\100@150x.Pdf\page_0.jpg
C:\viewer-cache\working\temp\FromURL\http___localhost_Content_Images_no-document-selected.png\2015-07-20T20_21_33\100@852x.Pdf\page_0.jpg
C:\viewer-cache\working\temp\FromURL\http___localhost_Content_Images_no-document-selected.png\2015-07-20T20_21_33\100@x.Pdf\page_0.jpg

I had expected all file access to go through the IStorageProvider instances given to Viewer.SetStorageProvider, but this doesn't seem to be the case.

What else can I do (via code) to make sure all files are encrypted?

Does the DocumentCache not use the tempStorageProvider that is passed into Viewer.SetStorageProvider?

I have been able to make sure the contents of c:\viewer-cache\root\temp are encrypted by utilizing


helper.Stream

instead of

helper.Url
Hello Tommy,

Thank you for your posting and using GroupDocs.Viewer.

We glad to hear that you have solved your issue independently.

But, if you will have more questions, please feel free to contact us.

------

Best regards,
Evgen Efimov

http://groupdocs.com
Your Document Collaboration APIs
Follow us on LinkedIn, Twitter, Facebook and Google+

This issue is not solved.

With the work around, the files in
C:\viewer-cache\root\temp
end up encrypted.

But the files under
C:\viewer-cache\working\Cache\temp\
Still are not encrypted.

What can I do to make sure they are encrypted also?
Hello Tommy,

We are sorry for misunderstanding.

We have managed to reproduce the same issue at our side. We have discussed with our product team and they will add this feature (encryption files from cache folder). We have logged this feature in our issue tracking system as WEB-1861. We have linked this forum thread to the same issue and you will be notified via this forum thread once this issue is resolved.

We apologize for the inconvenience.

------

Best regards,
Evgen Efimov

http://groupdocs.com
Your Document Collaboration APIs
Follow us on LinkedIn, Twitter, Facebook and Google+

Will the expected solution either have the DocumentCache class utilize the temporaryStorageProvider setup in Viewer.SetStorageProvider?


Will there be an IDocumentCache interface that we could implement to perform our own caching? Maybe with a Viewer.SetDocumentCache method?

What is the expected timeframe for WEB-1961?

Hello Tommy,

Thank you for your inquiry.

We have discussed with our product team your questions and they said that you will have an opportunity to use just temporaryStorageProvider for encryption .

About the expected time-frame - our product team is working on this issue already and they will try to add this feature in new release of the GroupDocs.Viewer that will be tomorrow or on Monday. But if this feature will not be resolved to this time, then it will be included in our next version, that can be released next month.

Thanks for your patience.

------

Best regards,
Evgen Efimov

http://groupdocs.com
Your Document Collaboration APIs
Follow us on LinkedIn, Twitter, Facebook and Google+

Evgen,


Was this fix included in the new release of GroupDocs.Viewer ?
Hello Tommy,

Thank you for your request.

Actually this issue has resolved at this time , but it not included in the release of the GroupDocs.Viewer for .NET 2.14.0. We plan to release the hotfix for this version next week and we think that this feature should be in this release.

You will be notified in this forum thread, when the feature will be released in our library.

Thanks for your patience.

-------

Best regards,
Evgen Efimov

http://groupdocs.com
Your Document Collaboration APIs
Follow us on LinkedIn, Twitter, Facebook and Google+

Just checking up on the status of this issue

Hello,


Thank you for the request. The new version of the Viewer (which will include fix for the issue) will be released at the end of this month. You will get notification when it will be ready.

Sorry for the inconvenience.

Good news:


This fix was published in GroupDocs.Viewer for .NET 2.15.0 as per


Bad news:

No one told me and I just stumbled upon the new version that had the fix when I got impatient and came to see the status of this issue.




Hello Tommy,


We are really sorry for that. In the latest version of the library where a critical bug which was resolved and this ещщл some extra time for testing and to ensure that it fixed. Since that the release was later then we expected. This way you have stumbled upon the new version before we notified you. Sorry this will not happen again.

Best regards.