[
https://issues.apache.org/jira/browse/PDFBOX-1453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14521871#comment-14521871
]
Tilman Hausherr commented on PDFBOX-1453:
-----------------------------------------
[~torakiki] please run your tests again, and then close or comment in the
issue, here's why:
After the change in PDFBOX-2769 (a few minutes ago), there's now a meaningful
error message ("PDF contains an encryption dictionary, please remove it with
setAllSecurityToBeRemoved() or set a protection policy with protect()") instead
of an NPE when saving. So you may ask: why can't just save() "do the right
thing" without complaining? Because the PDF can be opened with user or owner
password, but both to save it. So the protection has to be set up again.
About the permissions in the second test: your file is still encrypted at that
time. I was testing a fix but then I found that this is not a fault, but a
feature: The javadoc of getCurrentAccessPermission() tells "If the document was
not decrypted this method returns the access permission for a document owner".
About the permissions in the third test: if you have owner rights then
canModify should indeed be true. I don't understand why you wrote "I can modify
the doc because I have owner permission but the Modify should be off".
[~lehmi] improvement suggestion for 1.8 only (as it applies to the old parser
only) so that the user isn't confused if he encounters the problem described in
my comment about the 2nd test:
{code}
public AccessPermission getCurrentAccessPermission()
{
if (this.securityHandler == null)
{
if (isEncrypted()) <----------- this segment is new
{
LOG.info("the document has not yet been decrypted, returning
access permission for a document owner");
}
return AccessPermission.getOwnerAccessPermission();
}
return securityHandler.getCurrentAccessPermission();
}
{code}
> NPE saving modified encrypted document
> --------------------------------------
>
> Key: PDFBOX-1453
> URL: https://issues.apache.org/jira/browse/PDFBOX-1453
> Project: PDFBox
> Issue Type: Bug
> Components: Crypto, Writing
> Affects Versions: 1.8.7, 1.8.9, 1.8.10, 2.0.0
> Reporter: Andrea Vacondio
> Assignee: Andreas Lehmkühler
> Fix For: 2.0.0
>
> Attachments: TestEnc.zip
>
>
> I posted this on the mailing list but got no answer. I'm describing here some
> behaviors that are triggering NPE when saving a modified pdf document.
> What I'm trying to do is to open an encrypted document, modify it, save it
> back (I attached my test project). The three tests I made they all end up
> with a NPE but they work if I turn on setAllSecurityToBeRemoved (and I don't
> want security to be removed).
> First test:
> 1- input is a doc encrypted with owner pwd having the modify permission on.
> 2- The document is loaded and decrypted using owner pwd.
> 3- permissions.isOwnerPermission() is true which is correct
> 4- permissions.canModify() is true which is correct
> 5- modify the doc and save throws a NPE which is NOT correct
> Second test
> 1- input is a doc encrypted with owner pwd having the modify permission on.
> 2- The document is loaded but not decrypted
> 3- permissions.isOwnerPermission() is true, why? I didn't provide any owner
> pwd I should not have owner permissions.
> 4- permissions.canModify() is true which is correct
> 5- modify the doc and save throws a NPE which is NOT correct
> Third test
> 1- input is a doc encrypted with owner pwd having NO permission.
> 2- The document is loaded and decrypted using owner pwd.
> 3- permissions.isOwnerPermission() is true which is correct
> 4- permissions.canModify() is true, why? I can modify the doc because I have
> owner permission but the Modify should be off.
> 5- modify the doc and save throws a NPE which is NOT correct
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
