[LOCKED] To what extent can we limit local saving of a PDF document located on a website?

[Under S.]

I just completed the first draft of a multi-page PDF document that I plan to share to a group of individuals for review via a link on my personal website (that I coded from scratch using HTML, CSS and limited PHP). No PDF editability or interactivity needed, these people just need to be able to view it. I'm not even sure this will be True PDF (selectable text) as it might just be flat pages, for this draft.

There are 3 behaviors I'm interested in with regards to this link (and document) :

1. That the link (ex: "website.com/folder/document.pdf") open the file in-browser.
2. That file saving be disabled (at least as much as it can be).
3. That the website not load the entire document, only the target page (or spread) assuming this is even possible.

I realize that if someone really wants to open the document in Acrobat, or save the document locally, they'll find a way, whether or not the "easy way" is available to them. I'm just trying to limit this as much as I realistically can. Can the usual "File / Save" or "Right-Click / Save" options be disabled?

The tools at our disposal are InDesign (meaning we can re-export a new version of this PDF if needed), PHP (though only for includes, we're not PHP experts) and finally : the site's .htaccess file.

How many of those 3 behaviors can I help influence, and how?

Thanks!

[BenPleysier]

1. See https://developer.adobe.com/document-services/docs/overview/pdf-embed-api/

2. and 3. are not Dreamweaver related. You will need to study the PDF documentation.

[Ben M]

For 2/3 I would post that in the Acrobat forum ( https://community.adobe.com/t5/acrobat/ct-p/ct-acrobat?page=1&sort=latest_replies&lang=all&tabid=all ) .  I know there are ways to proctect documents with security via Acrobat. I don't know if these options are available in InDesign though as that is designed just to format your document and not provide security to it, but if you have DW and InDesign, I can only assume you have the entire Creative Cloud suite and not a single product subscription so you should have access to Acrobat to accomplish the security features you need.

[Under S.]

I wasn't aware of the API, thank you. I'd be curious to see it used in the wild, have you used it on one of your websites? It seems to require ID #'s we have to apply for, that are tied to specific accounts/websites. This may very well suit our purposes for the polished magazine; but for these draft versions, I don't know how comfortable we are with the data-sharing, or how involved the whole process appears to be.

In the very short term, other than the API, what can I do to "encourage" (because AFAIK, forcing is impossible) the "website.com/folder/document.pdf" link to open in-browser (whatever the default may be)? Even if it's not an elegant solution, I'd like to know what my options are, in 2022. Can the .htaccess file not be of some help, here? (I'm no .htaccess expert, I've just been surprised in the past about everything this file can do.)

As for loading the document progressively, or disabling save options, I will head to the Acrobat forum as you've both recommended. Thanks again.

[BenPleysier]

In the very short term, other than the API, what can I do to "encourage" (because AFAIK, forcing is impossible) the "website.com/folder/document.pdf" link to open in-browser (whatever the default may be)?

By @Under S.

I suppose you could always embed the document as in

<embed src="website.com/fo;der/document.pdf">

which will produce

See https://developer.mozilla.org/en-US/docs/Web/HTML/Element/embed 

[Nancy OShea]

Not sure if this is what you're intending but Acrobat supports Adobe Sign.  In other words, you send PDF to designated people to review, complete and e-sign.  Afterwards you receive digital confirmation.  Only the people you designate can see the document.  After a while the digital invitation expires.  And since it's legally binding, they cannot edit the document.

If you've ever used DocuSign, Adobe Sign is very similar.  It's typically used for real estate, employees, government, legal/court documents. 

https://www.adobe.com/sign.html

Hope that helps.

[Under S.]

I look forward to trying Ben's embed code, tomorrow. And Adobe Sign will likely come in handy for something else we had in mind (I'm reading up on it right now). Thank you to you both.

I've also come across this page that seems to confirm that .htaccess actually CAN be used to force-open a PDF file in-browser. But I'll admit I don't fully understand what I'm reading, as I'm a pretty basic html/css guy. This is almost a shot in the dark, but... is this the code that would do it?

<FilesMatch "\.(?i:pdf)$">
    ForceType application/octet-stream
    Header set Content-Type application/pdf
    Header set Content-Disposition inline; filename="filename.pdf"
</FilesMatch>

 Would simply adding the above to my .htaccess file do the trick?

And if so, I assume those quotes at the end imply an exact filename, right? Does this mean it will recognize the filename no matter where it's located on the website, or do I need to specify a path here? Could I add wildcards like "magazine*.pdf" so every PDF file beginning with "magazine" opens in-browser, across the entirety of the site? (Apologies if I'm getting ahead of myself.)

Gracias!

[BenPleysier]

The .htaccess code forces the PDF file to download rather than show it in the browser and allowing the user to download/print at their leisure.

To apply the instruction to all PDF files use

<FilesMatch "\.(?i:pdf)$">
ForceType application/octet-stream
Header set Content-Disposition attachment
</FilesMatch>

Please be reminded that a .htaccess file will only work under an Apache server, hence not in a Windows, Nginx or NodeJS server.

Personally have not used .htaccess in ages due to Nginx and lately, NodeJS.

[B i r n o u]

Well, everything will depend on the number of simultaneous connections needed, and on the needs of resources, but we could say that in a big majority of cases, and of site or app, to use Nginx as a reverse proxy of an apache server allows , allows to have the cake and eat it too, and thus to continue the use of .htaccess

[BenPleysier]

@B i r n o u, I guess that my reason for not wanting to use a .htaccess file, even if I could, is because I hate having to download a PDF file only to find that it was not what I was looking for.

I prefer being able to preview the file before deciding whether to download or print. Embedding the file as I have shown gives the option of printing or downloading. Not sure what the Adobe API does, I assume much the same.

[B i r n o u]

Sorry if I misspoke, I agree with you 100% on the fact of previewing PDFs directly from the browser (well it doesn't avoid their downloading in the cache), but it allows us to continue browsing within the same tool, and to make sure of the relevance of the search.

In fact I was just referring to the possible use of .htaccess with Nginx. I remember the long and heated discussions, a long time ago, where we were together, alone to defend the use of Nginx 😉 you went further than I, relying only on Nginx... I still depend... somewhere on Apache

[Under S.]

I was under the impression that "Content-Disposition inline" keeps it in the browser, while "Content-Disposition attachment" downloads it. It also makes more sense to me that way just based on their names.

Are you claiming it's the opposite? Because you're asking me to trade "inline" for "attachment" when my goal is to keep it in the browser.

[BenPleysier]

My bad, you are right.

[Under S. · Accepted solution]

The site was nagging me to close the thread, so since no single reply was the correct one, I'm pasting a couple of the solutions I found elsewhere before closing.

To open PDFs in-browser on Apache servers (like mine) add this to .htaccess:

<FilesMatch "\.(?i:pdf)$">
    ForceType application/octet-stream
    Header set Content-Type application/pdf
    Header set Content-Disposition inline
</FilesMatch>

As for discouraging downloads (plan B if disabling wasn't possible) turns out simple CSS can do that for ANY element, by removing the most common context menu access point, via :

pointer-events: none;
-webkit-touch-callout: none;

None of this prevents anyone from saving the PDF to drive, but it does help steer most of the herd towards viewing in-browser and moving on. Maybe this will help someone else looking to do the same.

[BenPleysier]

I think it a poor solution when an htaccess file is involved. Especially when my first reply is the Adobe solution and my second reply allows me to do this

https://youtu.be/KSeDAHcf1Xw

[Under S.]

None of which curbs saving. If anything, that embed API makes the SAVE option more visible and attractive (as your video just demonstrated). And don't you have to apply for a unique ID from Adobe to use it? Meaning surrendering some measure of privacy to Adobe to boot.

My concern was never that users wouldn't be able to open the thing, it was that it might open in Acrobat, or into a Save prompt, as default behavior. Or that the Save options may be too accessible, even if they cannot be entirely disabled. It's nothing personal.

PS: Writing "I think it a poor solution when an htaccess file is involved" without stating why helps no one. A lot of people find .htaccess very useful.

[BenPleysier]

You can disable Print by adding security to the PDF with the Protect tool and disallowing Print. 

https://helpx.adobe.com/acrobat/how-to/password-protect-pdf.html?set=acrobat--fundamentals--secure-p... (not Dreamweaver related)

If that does not work then the following is possible:

<embed
  src="http://URL_TO_PDF.com/pdf.pdf#toolbar=0&navpanes=0&scrollbar=0">

Regarding htaccess:

https://www.danielmorell.com/guides/htaccess-seo/basics/dont-use-htaccess-unless-you-must

[Under S.]

You can disable Print by adding security to the PDF with the Protect tool and disallowing Print. 

https://helpx.adobe.com/acrobat/how-to/password-protect-pdf.html?set=acrobat--fundamentals--secure-p... (not Dreamweaver related)

And again, where did I ask for PRINTING to be disabled? Why do you keep trying to solve straw man problems? Curbing local saving of the document was the goal. As for not using htaccess, even the random opinion piece you deferred to concludes that it's not a big issue if you use just one htaccess file at the root of your site with minimal commands. Which just happens to be my situation.

Pardon my bluntness, but it's really starting to look like you're crapping on every solution that isn't yours just because it wasn't yours; before building straw man problems you actually DO have solutions to. Is this the flipside of gamifying online forums with awards & badges? If it's so important for you to have the correct answer, try to working WITH the people you're trying to help.

PS: Please don't reply with a way for me to play sounds on my website or log visitor IPs. No more straw men issues. You're making me regret returning to the thread to close it properly. Let us move on from this.

[BenPleysier]

You sound like a pleasant fella.

Hereby I invite you to my 80th birthday next May when we can have a decent discussion on my 50+ years of information technology. versus your ??? years.

Hope to see you down under.

[Nancy OShea]

I'll bring cognac & party hats. 😃

[BenPleysier]

@Nancy OShea ‍ you are on the VIP list of invitees!