We have requirement from client , They would like to add Same Signature in all pages (Know the PDF 2.0 Specification contradicts this one )
I ve succeeded some what(not i desired) in implementing the using Itext7.0.4 and itext 5.X
Using Itext 5.X: :
Added "
for (int p = 1; p <= writer.reader.getNumberOfPages(); p++) {
writer.addAnnotation(sigField, p);
} In PdfSignatureAppearance.java class it worked but in the signature panel on left side is showing only one signature
Ive seen the multiple appearance pdf, shows all pages signature in signature panel.
Kindly tell me is it right way of doing (ignore the PDF 2.0 specification ) and how to show all page signature in signature panel
Using Itext 7.0.4
its working as per https://github.com/mkl-public/testarea-itext7/blob/master/src/test/java/mkl/testarea/itext7/signature/ChangeSignatureAppearance.java
But its a 2 step process 1. creating Invisible signature pdf 2. Adding same signature to all pages
It is possible to do this in single step
If not possible kindly tell me which classes need to change or any work around option .
Related
I'm trying many functionality on jsReport and word and got stuck on this one.
I want to create an asset usable in different template, assuming that my asset got the right data.
Using this documentation and the UI jsReport Studio I create a working template called test-word, I upload a docx test_jsReport.docx with some ahnddlebar in it, create some data and it work.
Then I create an asset, in the same folder, with a second docx test_jsReport2.docx ; put some code and try to generate it alone with the same data, it worked again.
At this point my project look like this :
test project
Then, using this chapter I add in my docx test_jsReport.docx the following code : {{docxChild "test_jsReport2.docx"}}.
So I can no longer run my report, the error is the following.
Report "test-word" render failed.
Error while executing docx recipe
(because) error when evaluating engine handlebars for template anonymous
(because) "docxChild" helper call failed
(because) docxChild helper requires asset parameter to be set
(system-helpers.js line 706:11)
704 |
705 | if (assetNamePathOrObject == null) {
> 706 | throw new Error('docxChild helper requires asset parameter to be set')
| ^
707 | }
708 |
709 | const docxChildInfo = {}
What is that aset parameter that I need to set ? And how to do it ?
I'm pretty sure that I should omehow declare some kind of link beween my two reports, but I can't find how to do that.
First I tried to use the asset property in jsReport studio on my report, like this :
first try
But it doesn't worked and I never really believe it, I think it's an option to define a link to the physical docx I modify, so I don't have to upload after each save.
Second I read and try to mimic some other systems I can find in the doc like this and that and but it's for HTML report not word.
Lastly I tried to reference my report using a script like this :
const jsreport = require('jsreport-proxy')
// Use the "beforeRender" or "afterRender" hook
// to manipulate and control the report generation
async function beforeRender (req, res) {
await jsreport.assets.registerHelpers('test_jsReport2.js')
}
It doesn't work either.
I'm a little lost here, what is the right way to use docxChild ?
Here is a link to an example of what I do : https://playground.jsreport.net/w/anon/Pm_vIEwF
Here is how I setup the example :
I prepared my two word
Right click > new entity > template
Select handdlebars and docx > next > next
Click on my template > in properties, in docx I upload my main.docx
Right click > new entity > asset > upload, i put my subreport.docx
The docxChild feature works by searching a docx asset and take the content of such docx and insert it into the docx it was called from. You have follow the right steps, but the only issue is that you are using different characters for the quotes in your docxChild helper call. It was perhaps not your intention, for example on macos i noticed that whenever i try to use " it replace it for the characters present in your docx, so maybe if you are using macos this is the problem you are having.
Your original template
What should look like to have it working
I've prepared a playground example with your same code but fixing the docxChild call to use the right quote characters "",
I’m using Typo3 (Version 6.2.14) and upgraded WEC_Map to version 3.1.3 because I saw a warning on my map which says that I need to use an API key for Google Maps.
So I’ve generated an API key for "Maps Static API" and inserted it in WEC Map Admin. (I’ve used the same key for Browser API Key and Server API Key. Only difference is that I’ve added the secret for the Browser API Key separated by a comma.)
If I’ve visit my FE User Map in the backend the map is showing.
In the frontend instead I get the following error: "
There doesn't seem to be anything to display. Make sure the map is configured correctly and there are users or markers set".
Inspecting the source code I saw that the script tag to maps.googleapis.com is not generated. It looks like this is causing the issue, but I don't know why it is happening.
I hope that someone using a similar setup can point me into the right direction.
Thank you guys. (It would be nice if someone could add the Tag for WEC_Map)
Ok I resolved this. The problem was that I was using the userGroups setting to filter the map markers by multiple user groups.
plugin.tx_wecmap_pi2 {
height = 500
width = 500
showDirections = 1
prefillAddress = 0
initialMapType = G_HYBRID_MAP
controls.mapControlSize = large
controls.showOverviewMap = 1
controls.showMapType = 1
controls.showScale = 1
userGroups = 2,3,5
pid = 2,3,5 # <-- This uses a AND condition
}
Since this setting is using an AND condition under the hood I received the error "There doesn't seem to be anything to display. Make sure the map is configured correctly and there are users or markers set"
In fact I opened a feature request for this 3 years ago. Unfortunately the feature request never made it into the plugin. But Jan Bartels posted a workaround as reply to the feature request. This workaround got lost while updating the extension.
Also recomment to the extension authors to make it more clear in their documentation that the property userGroups uses a AND condition.
This link (Document) contains a digitally signed PDF that is correctly verified by IText (version 5.5.12) but not by Adobe Reader DC which issues the following message:
Error during signature verification.
Unexpected byte range values defining scope of signed data.
Details: The signature byte range is invalid
Whos is correct? Adobe DC or IText? IText Bug?
Sample ITextSharp code used to PDF digital sign verification:
using System;
using System.Collections.Generic;
using iTextSharp.text.pdf;
using iTextSharp.text.pdf.security;
namespace ClassLibrary1
{
public class Class1
{
public Boolean PDFVerify(String file)
{
PdfReader pdfr = new PdfReader(file);
AcroFields af = pdfr.AcroFields;
List<String> names = af.GetSignatureNames();
foreach (String name in names)
{
PdfPKCS7 pk = af.VerifySignature(name);
if (!pk.Verify()) return false;
}
return true;
}
}
}
The problem is that the PDF itself is broken.
The PDF has two revisions,
a first revision apparently created using "Marvell Semiconductor, Inc. -- http://www.marvell.com" (according to the Producer info dictionary entry)
an incremental update to a second revision containing the signature apparently created using iTextSharp 5.4.3.
The first revision is broken in many ways, two obvious errors are:
Invalid header; according to ISO 32000-1 the first line of a PDF file shall be a header consisting of the 5 characters %PDF– followed by a version number of the form 1.N, where N is a digit between 0 and 7. Here the header line is
%PDF-1.4 Marvell Semiconductor
The above quoted rule does not allow for more than %PDF-1.N.
Invalid cross reference table entries; according to ISO 32000-1 each entry shall be exactly 20 bytes long, including the end-of-line marker. Here each entry is only 19 bytes long, including the end-of-line marker.
There might be more less obvious issues.
There are no obvious errors in the incremental update to the second revision.
When Adobe Reader opens this file, it recognizes that it is broken, creates a repaired version internally, and from now on uses this repaired version. When the signature is verified, it is verified in this repaired version. Such repairs, though, obviously will change the hash of the PDF and most likely will move the position of the signature. The signature byte range is expected to be the entire file, including the signature dictionary but excluding the signature value itself. If the repair moved the embedded signature, this requirement is not fulfilled anymore, resulting in the observed error message.
When iText opens this file, it probably also recognizes the errors but it merely creates its internal cross reference table and for every purpose besides cross reference lookups, it still works with the original file. Thus, the hash is correct and everything is located where it belongs, resulting in a verification success.
This question already has an answer here:
PDF/A signed with iText7 allows changing attached documents without breaking a signature
(1 answer)
Closed 4 years ago.
I used nitro pro 10/11 to edit a signed PDF document.
Adobe reader can recognize the docs content has been modified, but integrity check is ok by iText (V5.5.6/V7.0.2).
How can i check whether the integrity is correct using iText?
iText offers an API to validate each integrated signature and to check whether it covers the whole document. It does not check, though, whether changes in incremental updates are allowed changes.
Some backgrounds
PDFs can be changed by a mechanism called incremental updates. This mechanism only appends to the file leaving the original bytes unchanged. With each such incremental update a new revision of the file is added to the file.
Integrated PDF signatures sign the complete revision of the document in which they were added to the file with the obvious exception of the actual signature bytes.
Thus, a signature of a former revision still correctly signs its byte ranges even if a later revision completely changes how the PDF is displayed.
As in common signing use cases content someone signed should not be arbitrarily changed, the PDF specification only considers very few types of changes in incremental updates to signed revisions valid, cf. this answer on stack overflow and the documents referenced from there.
What iText's API offers
iText offers an API to validate each integrated signature, in particular this validation checks whether that integrated signature correctly signs the bytes it applies to.
iText furthermore determines whether a signature covers the whole file, i.e. the latest revision of the file.
iText does not offer simple API functions, though, that check whether the changes in incremental updates to signed revisions are all allowed.
This task actually is decidedly non-trivial as the allowed changes are not specified in deep detail; I am not aware of any proper open source implementation of it. Even Adobe Reader in its code for this check has many false negatives for PDFs in which the allowed changes are implemented differently than Adobe Reader would have done it itself, e.g. see this answer.
iText does offer the low-level tools to implement such tests, though, so anyone is welcome to implement them on top of iText.
iText checks in code
You can execute the checks with iText 5.5.10 like this:
PdfReader reader = new PdfReader(resource);
AcroFields acroFields = reader.getAcroFields();
List<String> names = acroFields.getSignatureNames();
for (String name : names) {
System.out.println("Signature name: " + name);
System.out.println("Signature covers whole document: " + acroFields.signatureCoversWholeDocument(name));
System.out.println("Document revision: " + acroFields.getRevision(name) + " of " + acroFields.getTotalRevisions());
PdfPKCS7 pk = acroFields.verifySignature(name);
System.out.println("Subject: " + CertificateInfo.getSubjectFields(pk.getSigningCertificate()));
System.out.println("Document verifies: " + pk.verify());
}
(VerifySignature test testVerifyBabyloveSigned)
The outputs for the OP's sample files are:
babylove_signed.pdf
===================
Signature name: Fadadaf1a333d3-d51a-4fbb-ad22-bbdcaddd7d8e
Signature covers whole document: true
Document revision: 1 of 1
Subject: {C=[CN], OU=[fabigbig, Individual-1], CN=[051#???#352229198405072013#2], O=[CFCA OCA1]}
Document verifies: true
babylove_signed&modify_by_nitro.pdf
===================
Signature name: Fadadaf1a333d3-d51a-4fbb-ad22-bbdcaddd7d8e
Signature covers whole document: false
Document revision: 1 of 2
Subject: {C=[CN], OU=[fabigbig, Individual-1], CN=[051#???#352229198405072013#2], O=[CFCA OCA1]}
Document verifies: true
As you see, signed.pdf has only one revision, its integrated signature is valid, and it covers the whole file. signed&modify_by_nitro.pdf has two revisions, its integrated signature is valid but it covers only revision one.
Thus, iText says that while the signature in the latter file does correctly sign its revision, there may be any amount of changes in the second revision.
I am using the following function to vertically align labels in a form.
Private Sub VerticallyCenter(ctl As control)
Dim lngHeight As Long
lngHeight = fTextHeight(ctl)
' Rounding will result in a 1 to 2 pixel margin of error
' of every control before it renders text.
ctl.TopMargin = ((ctl.Height - lngHeight) / 2)
End Sub
However, when I compile it, it says that fTextHeight() is not defined. I have the same error on other "classic" VBA Access functions as DirectCast() or CType(). It looks like my Access is not loading VBA Libraries.
Found it!
Like I said, fTextHeight is a custom function. It is contained in the module modTextHeightWidth in the zipped .mdb downloadable from here: http://www.lebans.com/textwidth-height.htm