jas*_*nes 2 pdf encryption password-protection tcpdf
我从这里开始写:
但由于我在这里的声誉,我无法添加评论(我在 AskUbuntu 上表现更好,但我不能从那里获取我的代表点)。我还在那里开始了赏金,如果有人在两天内在这里回答并提供可接受的解决方案,我将在那里奖励。
现在,问题是:SetProtection 方法没有按预期工作。
想要的行为:使用 TCPDF 库创建受保护/加密的 PDF 文档,以便始终向每个人授予文档视图而无需询问任何密码,但如果尝试编辑,则需要密码。
我使用以下语法:
$pdf->SetProtection(array('修改', '复制', '注释表单', '填充表单', '提取', '汇编'), null, 'mypwd', 1);
正确的语法是什么(如果有),让每个人都可以阅读 pdf,但只能使用提供的“mypwd”进行编辑?
编辑:
您将看到一个带有空白用户密码和强主密码的文件。Ilovepdf.com 发现它已解锁,Libreoffice Draw 可以对其进行编辑。这不是预期的行为。
https://www.dropbox.com/s/864p8xjh1ue041z/tracking_12750_16.pdf?dl=0
据我所知,您的示例 PDF 已按照您想要的方式加密,使用空的用户密码和非空的所有者密码。因此,TCPDF 正是按照要求去做的。
最有可能的问题是您的期望太强烈:如果一个程序可以打开 PDF 进行阅读,那么该程序就可以对 PDF 执行任何操作,无论它的配置有多么限制。权限以及不同的所有者和用户角色需要相关软件的配合,但在技术上并未强制执行。
从规范中已经清楚地表明了这一点:
一旦文档成功打开并解密,PDF 阅读器从技术上讲就可以访问文档的全部内容。PDF 加密中没有任何固有的内容来强制执行加密字典中指定的文档权限。PDF 阅读器应尊重文档创建者的意图,根据文件中包含的权限限制用户对加密 PDF 文件的访问。
(ISO 32000-2,第 7.6.4 节标准安全处理程序)
显然,Libreoffice Draw 的行为根本不符合 PDF 规范的要求,即它没有根据文件中包含的权限正确限制用户对加密 PDF 文件的访问。可能是设计使然,也可能只是一个编程故障。
您应该简单地意识到您的期望
使用 TCPDF 库创建受保护/加密的 PDF 文档,以便始终向每个人授予文档视图而无需询问任何密码,但如果尝试编辑,则需要密码。
不能使用任意 PDF 处理器的标准 PDF 加密设施来实现,仅适用于那些遵循上面引用的 PDF 规范要求的处理器。
有一些 PDF DRM 软件解决方案提供商并不那么容易规避,但我怀疑它们中的任何一个都无法抵御坚定的黑客。(除非所讨论的解决方案根本不向用户提供 PDF,而只是在基于 Web 服务的自定义查看器中提供图像;但这不是您的用例。)
根据您的实际需求,您可能想研究使用数字签名而不是加密;如果您的目标是确保任何收件人都可以确定他收到的是您的文档内容,而不是其他人编辑的内容,那么这似乎更合适。
| 归档时间: |
|
| 查看次数: |
1909 次 |
| 最近记录: |