getRangeStream
is not the only method that was refactored from PdfSignatureAppearance
to PdfSigner
and made protected
on that way. The same problem exists for other methods, too, like preClose
and close
which are also methods used in the PreSign
and PostSign
servlets from Digital Signatures for PDF documents which you seem to use or at least borrow code from.
This, as I presume, has been done to make iText 7 users use the signDeferred
, signDetached
, and signExternalContainer
methods which usually are sufficient for signing applications and "do it correctly", i.e. use the other, now not anymore public methods in a way that creates valid signatures.
The PreSign
and PostSign
servlets as they are unfortunately cannot use those three methods, they actually are like the signDetached
code ripped in two halves with the relevant local variables stored in the HTTP session.
Thus, you essentially have two choices:
Use the protected methods nonetheless
Unless I overlooked something, this can even be done by deriving your own signer class from PdfSigner
and making those methods and probably member variables publicly accessibly again; using reflection magic at first sight doesn't seem necessary.
Change the PreSign
and PostSign
servlet architecture
If you could switch from keeping those signing related objects in memory (referenced via the HTTP session) to merely keeping an intermediary PDF file in memory or even on disk and probably the half-baked signature container in memory, you could proceed like this:
Replace the PreSign
servlet by a servlet that "signs" the PDF using PdfSigner.signExternalContainer
with a IExternalSignatureContainer
implementation that merely provides a dummy signature, e.g. new byte[0]
.
This IExternalSignatureContainer
retrieves the sought-for range stream as parameter of its sign
method, so it can calculate the range stream hash.
Now the PDF with the dummy signature can be saved to disk or held in memory. And based on the range stream hash you can continue constructing and feeding the PdfPKCS7
instance as before. And hold that in memory, e.g. referenced from the HTTP session.
Replace the PostSign
servlet by a servlet that as before finishes feeding the PdfPKCS7
instance and generates a CMS signature container. Then inject this container into the saved PDF using the PdfSigner.signDeferred
method.
Alternatively you could even move the whole CMS signature container creation to the client. In that case all the session has to remember is where the intermediary PDF is stored...
Some inspiration may come from the C4_09_DeferredSigning.java iText 7 example.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…