Adam...below On Aug 25, 2011, at 7:46 PM, Adam Nichols wrote:
> AccessPermission can be used without encrypting the PDF. That's why I > said it is not related to encryption. I would be very interested in knowing how you do that. Searching the PDFBox 1.4.0 tree, I can only find uses of AccessPermission in conjunction with encryption. --Ken > > However, if you are encrypting something, AccessPermission will be > used. So I'd still say that AccessPermission is not related to > encryption. If you had to encrypt the file in order to use > AccessPermission, then I would agree that it is related to encryption. > > On Thu, Aug 25, 2011 at 6:02 PM, Ken Bowen <[email protected]> wrote: >> Hello Adam, >> >> Thanks for the reply. Unfortunately, we're not interested in encrypting the >> form; only in preventing >> further changes beyond a nominal "finished" point. I was only hoping for a >> "global" way of doing that. >> >> I think you may have made an error when you said >> >>> Now, to answer your question, the AccessPermission class is not related >>> to encryption, >> >> Since org.apache.pdfbox.pdmodel.encryption.AccessPermission is part of the >> encryption package, >> and since it also used as a argument to the StandardProtectionPolicy and >> PublicKeyRecipient >> constructors, it is clearly "related" to encryption. >> >> Regards, >> Ken >> >> On Aug 25, 2011, at 12:21 AM, Adam Nichols wrote: >> >>> Hello. >>> >>> First, let me explain what the options are in terms of protecting a PDF. >>> There are three different types: >>> 1. No protection. There's no encryption, no passwords, and anyone with >>> the right software can read, modify, extract, print and whatever else >>> they desire. >>> 2. PDFs with an owner password. These can be opened and read by anyone, >>> however there are some flags which are set which say "please don't edit >>> this", "please don't print", and so forth. From a technical standpoint, >>> there's nothing stopping anyone from doing these prohibited actions, but >>> most software will respect these flags and only allow you to preform >>> prohibited actions if you enter the correct owner password. >>> 3. Then there are PDFs with a user password. These can not be opened, >>> read, or processed in any way without the user password. There is >>> encryption (RC4 or AES) which stops anyone from bypassing this, no >>> matter what software they use. Once the correct password is entered, >>> the file is decrypted and it treated like #1 or #2. >>> >>> Now, to answer your question, the AccessPermission class is not related >>> to encryption, however it is related to the owner password. You will >>> not need to enter a password to open protected files (as long as there's >>> no user password); you will only need the password to edit them. Just >>> keep in mind that it's only going to stop people who didn't REALLY want >>> to edit it. >>> >>> There's no way to use strong encryption to enforce the editability of >>> the file. As long as the program can process the file enough to know >>> what to render, then it has everything it needs to write out a copy and >>> modify the copy. >>> >>> Hope this helps you understand how PDFs work, and how the class works. >>> >>> --Adam >>> >>> On 08/24/2011 08:19 PM, Ken Bowen wrote: >>>> Hi Everyone, >>>> >>>> We have routines which create and fill out pdf forms using PDFBox. >>>> After creating and filling the fields, we need to make all of them >>>> read-only. >>>> Is there a global way to do this with PDFBox for a form? >>>> Or do I need to go through and apply PDField.setReadonly(true) to each >>>> field? >>>> >>>> I've observed that org.apache.pdfbox.pdmodel.encryption.AccessPermission >>>> has a bit for setting fields read-only, but it seems this class is only >>>> related to encyrpted PDFs -- is this true? >>>> >>>> Thanks in advance, >>>> -- Ken >>>> >> >>
