Welcome to OGeek Q&A Community for programmer and developer-Open, Learning and Share
Welcome To Ask or Share your Answers For Others

Categories

0 votes
1.5k views
in Technique[技术] by (71.8m points)

java - In Itext 7, how to get the range stream to sign a pdf?

I'm trying to migrate my application from iText 5.5.9 to iText 7 and I have a problem with signing a document on the server using a signature created on the client (described in the Digital Signatures for PDF documents).

As the getRangeStream() method isn't public anymore as it was in iText 5.5.9, how can I obtain a reference to the range stream?

See Question&Answers more detail:os

与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
Welcome To Ask or Share your Answers For Others

1 Reply

0 votes
by (71.8m points)

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.


与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
OGeek|极客中国-欢迎来到极客的世界,一个免费开放的程序员编程交流平台!开放,进步,分享!让技术改变生活,让极客改变未来! Welcome to OGeek Q&A Community for programmer and developer-Open, Learning and Share
Click Here to Ask a Question

...