I’m having trouble displaying files from Amazon S3 through ngx-doc-viewer when using temporary signed URLs. The documents won’t show up properly in either Google’s document viewer or Microsoft’s online viewer.
My Setup:
I create a signed URL from my S3 bucket and verify it works by opening it directly in a browser. Then I try to display it using the Google viewer like this:
Had the exact same nightmare building a contract review system. External viewers just can’t handle signed URL auth complexity.
Skip the proxy wrestling and PDF conversion headaches - automate the whole document pipeline instead. Set up a workflow that intercepts requests, grabs files from S3 with proper credentials, then serves them through clean public endpoints that viewers actually work with.
The automation handles format detection and conversion automatically. Word docs become PDFs, images get optimized, everything gets cached with smart expiration. No more auth token nightmares or compatibility issues.
Just point ngx-doc-viewer to your automated endpoint instead of raw S3 URLs. The pipeline deals with S3 complexity behind the scenes and gives you reliable previews.
Bonus: add security rules to the automation. Log access, watermark sensitive docs, restrict by user permissions. Way more control than hoping external viewers cooperate.
I built my entire document automation system with Latenode. It handles S3 integration, format conversion, caching, and serves clean URLs all in one workflow.
I’ve dealt with this exact headache integrating document previews in our enterprise app. The problem is Google and Microsoft viewers need public access to crawl and cache docs, but that breaks S3’s signed URL auth. Tried a bunch of workarounds before settling on PDF-lib for backend document rendering. Skip the external viewers completely - you get full control that way. Just grab the S3 file server-side with your signed URL, convert it to something web-friendly, and serve through your own endpoint. For ngx-doc-viewer, set the viewer type to ‘pdf’ and serve converted docs. Way more reliable than depending on external services. Yeah, there’s some processing overhead, but no more auth conflicts and much better document security. Pro tip: cache documents based on file modification timestamps. Saves you from redundant S3 calls and conversions. Been running this setup in production for over a year - rock solid.
Yeah, this is a super common issue. Google and Microsoft viewers can’t handle private S3 URLs - they need to fetch files from their own servers first, and signed URLs with auth parameters often break them.
I hit this exact problem building a document management system last year. Fighting with third-party viewers is a pain, so I built an automation workflow instead.
Here’s what works: create a pipeline that converts docs to viewer-friendly formats and serves them through clean endpoints. When someone requests a document, the automation grabs it from S3, processes if needed, and returns a public URL that works with any viewer.
Set up automatic conversion too. PDFs work great with most viewers, so convert Word docs or other formats to PDF first. The automation handles caching so you’re not constantly hitting S3.
This kills the signed URL headaches completely. Your frontend just requests a clean document URL and everything works.
I built the whole system with Latenode since it handles S3 integration, file processing, and API endpoints in one workflow. Way simpler than managing separate services.
This bit me hard when I was building document previews for a legal tech platform. Google and Microsoft viewers are basically web crawlers - they fetch docs from their own servers, so they can’t handle your S3 signed URLs. I fixed it with a simple middleware setup. Created a document service that sits between ngx-doc-viewer and S3. When someone wants to view a doc, the service grabs it using the signed URL, caches it briefly, and serves it through a clean public endpoint. The trick is you don’t need permanent public access - just make the doc temporarily available through your own domain while they’re viewing it. I auto-delete after 10 minutes, which is more than enough for most sessions. Make sure your middleware strips S3-specific headers and sets proper MIME types. Works great with ngx-doc-viewer’s Google mode and you won’t need format conversion or crazy proxy stuff.
Been wrestling with this exact thing for months on a client project. The problem is Google and Microsoft viewers need to crawl documents from their servers, but S3 signed URLs have temporary auth tokens that break their fetching process.
What finally worked was creating a proxy endpoint on my backend. Instead of passing the S3 signed URL directly to the viewer, I made a route like /api/document-proxy/:fileId that grabs the file using the signed URL and streams it back with proper headers. This gives the external viewers a clean, public URL without any S3 auth parameters.
You need to set the right Content-Type and Content-Disposition headers when streaming through your proxy. I also threw in some basic caching so it doesn’t hammer S3 for the same document while the URL’s still valid.
For ngx-doc-viewer, just use the proxy URL instead of the raw S3 URL. Works great with both Google and Microsoft viewers now. Make sure your proxy handles CORS properly if you’re calling from a different domain.
i tried this last month - S3 signed URLs don’t work well with external viewers because of auth header issues. switched to Mozilla PDF.js instead of ngx-doc-viewer. works much better for private files since it renders everything client-side without Google or microsoft needing to fetch anything.