Pdf.js: Digital signatures in pdf.js

Created on 13 Jan 2012  ·  174Comments  ·  Source: mozilla/pdf.js

Hi! We are interested about when or if you´re going to implement the Signature Data View (Xades, Pades & Cades) in the PDF viewer (PDF.js)

Kind Regards

Alejandro Pinedo,
SOA-X

2-feature 4-annotations

Most helpful comment

To all the people above, please make use of GitHub's new +1 reaction button instead of adding comments here.

All 174 comments

There are currently no imminent plans to implement this feature. We haven't seen it come up much so it hasn't been a priority. We're always looking for more contributors though, so we'd welcome any patches to add this feature. If you're interested in adding it feel free to stop by our IRC channel(#pdfjs irc.mozilla.org) if you have questions.

Brendan

Hi

what is the present state on the implementation of this feature?

Thanks

@fermo111 Not implemented yet, but I will be glad to coach somebody who is willing to take this task.

@yurydelendik I'm interested in implementing the feature of presenting digital signatures of PDF files in pdf.js. How can I contact you?

@wolvz please find me at IRC irc.mozilla.org channel #pdfjs (that's simplest) or join any of our public meetings to coordinate stuff.

I'm trying to implement SigWidgetAnnotation (like TextAnnotation, LinkAnnotation), in annotation.js, for supporting digital signatures in pdf.js.
The signature is showing up in the pdf viewer, and I already can extract and verify the certificates embbeded in the DER-encoded PKCS7 object...
Now I'm moving into the next step, which is to verify the message digest of the file.
For that I need to have access to the file contents... I dont' know if it's possible or not to have access to that from annotation.js, but I can't figure it out. The best I could do was to get the contents in core.js using:

var contentStreamPromise = this.pdfManager.ensure(this, 'getContentStream',[]);
var dataPromises = Promise.all([contentStreamPromise]);
dataPromises.then(function(data) {
var contentStream = data[0];
var contents = contentStream.str.bytes;
return contents;
});

Can someone please enlighten me on what is the best way to get file contents in annotation.js?
Thanks in advance...

wolvz,
any progress in this regard?

@yurydelendik @wolvz
I am extremely interested in the digital signature display feature. I cloned wolvz's repository and built the code but when I try to use it, I'm getting a promise rejection with this error: "require is not defined". Could anyone explain what would cause that error and how I could fix it? Also, I am very willing to continue the work on this feature. I've worked with pdf's in Java via the iText library but working with them in javascript is something I've never tried before. Could someone direct me to some documentation/tutorial that could get me pointed in the right direction so that I can figure out where to start as I try to move this feature further down the field?

I am confused. What i have to do in my pdf.js library to show digital signature pdf in pdfJS

untitled

This signature and certificate both showing in pdf.. but when i open it in pdf.js it wont showing there.

@mrpandya007, the digital signature doesn't show because the developers chose to hide it until they have signature verification feature working.
If I recall, if you want them simply to show up you have to comment lines 389 to 392 here: https://github.com/mozilla/pdf.js/blob/master/src/core/annotation.js#L389
Not sure though, and I can't test it right now.

@wolvz, Thanx for the response but its already commented. PLease look into this,, Crystal report's generated pdf signature is not showing but DevExpress generated pdf is showing it properly

Please answer me .... what i have to do.. I can give you that pdf to test

There is no good support for digital signatures yet, so this will have to be implemented.

How many days it will take to fix this problem of digital signature because we are dependent on your lib.

It might take a long time as this feature will have to be developed by someone and there are currently higher-priority issues.

heading

Why i am facing such issue of "=" sign in Headings, only in pdf.js, after downloading the file it gone.
any solution please. It is happens only in telerik generated pdf.

@mrpandya007 Please do not post unrelated issues inside other issues. Open a separate issue for that problem.

I also encountered the same problem. While I don't necessarily require the signature validation it would be in my case sufficient enough to just show the signature image. Maybe till signature validation is implemented instead of not showing the image it would be better to show the image and annotate it with a small text that says something like "Signature validation not implemented. Signature status unknown"? So at least visiually the pdf would show what you would expect.

Is there a timeline for when this issue will be addressed? Or should we consider another product?
pdfjsissue

Nobody is working on this yet as far as I know, so if someone is willing to work on this, feel free to submit a PR.

Hi,
A PDF.JS version that is able to only displaydigital signature fields should be enough for many users... Is there any "fork" who is able to do this ?
Regards

@DORNINEM you just need to comment out the piece of code that hides the signature annotations.
But anyway, here is the fork you asked for: https://github.com/wolvz/pdf.js

@wolvz !! Thanks a lot.
I'm wondering why this feature is not in the official version, as it wokrs very fine. I tested with some of my signed PDF files (from 1 to 6 different signature fields) and the result is perfec !
I'm really sure that the real need is to display these fields, not to validate the signature. Signature validation is best done on the server side as it require some times certificates not installed on a local certificate repository.

Hello,

Someone can explain which line we have to comment or uncomment to allow pdf.js to display the digital signature ?

Thanks for all information :)

@maximlefebvre According to https://github.com/wolvz/pdf.js/commit/7df3f4fe6e21b888358fd7718cb15e3c266ba066, that should be enough to let PDF.js display the signature. Note however that this has not been verified by the PDF.js team as a stable solution (hence why it is not in the official codebase yet), but it might work as a temporary solution.

We are interested in implementing signature verification. It seems @wolvz started work on this but didn't complete it - do you have any partial code that we could work on top of?

@wolvz , can you please help us by making a small note to understand your repo. I am unable to understand how to start checking your code. We are trying to implement signature and we may be able to complete your project and help the community.

We have implemented both signing and signature verification of PDFs in browser using https://pkijs, you can see an early signature verification demo here: https://pkijs.org/examples/PDFexample.html we have not yet integrated with PDFjs but will be doing that in the not so distant future. Our intention is to release most of this as OSS and give back any changes to PDFjs that are necessary to make integration smooth.

Awesome, thanks @rmhrisk! However, I am not sure how to create a CA bundle file. Do you have details on how to do so? I would imagine when this is integrated with pdf.js it would be more "plug and play" where it comes with Adobe Root CA by default and can verify the certificate chain, right? And do you have a expected timeline for pdf.js integration? Your work is greatly appreciated!

There is one here: http://curl.haxx.se/ca/cacert.pem and one checked into the repository under samples.

There is a tool to create one here: https://github.com/PeculiarVentures/tl-create

I can't share an ETA at this time, we are limited on resources and this is important to us but we need to finish some more complex parts first.

I tried the one you linked to, as well as some certificates I tried to extract from the PDF using Adobe Reader, but I always get the error "TypeError: Cannot read property 'signature_time_stamp' of undefined" (in Safari/Chrome stable/Chrome canary).

I happen to have some time this coming week, so let me know if I can help with the merging into pdf.js in any way.

That sample only supports basic signatures, no timestamping or LTV at this time. Feel free to ping me at rmh at unmitigatedrisk dot com

Ah, I see. For reference, finally got it to work in Chrome/Firefox (but not Safari, which apparently only supports prefixed WebCrypto) using this CA bundle and this PDF file.

Yes that too, its not only the prefixed issue but they also only support enough webcrypto to handle netflix drm cases. For example they dont let you export the public key for a keypair you generate!? This is a good resource for verifing browser support - https://diafygi.github.io/webcrypto-examples/

@viveksjain Can you confirm how you got it working in Chrome/Firefox

I've tried using the development plugin in firefox however it still appears to fail to show signatures.
http://mozilla.github.io/pdf.js/extensions/firefox/pdf.js.xpi

@complience he got the sample code located at https://pkijs.org/examples/PDFexample.html working not PDFjs

Hi @complience, I have a proof-of-concept working at https://github.com/viveksjain/pdf.js/tree/sig-verify-support. You can try it by using git clone --recursive https://github.com/viveksjain/pdf.js.git. With a little bit more work it should be ready for a pull request into this repo, but I just haven't had the time yet.

@viveksjain nice! What is still needed before it is ready for a pull request?

+1 Delighted to get this functionality.

Yes this will be a great value add to the community, opening the door for many use cases. Thank you!!

+1 for this functionality

+1 for this functionality

To all the people above, please make use of GitHub's new +1 reaction button instead of adding comments here.

+ 1 for this functionallity

👍 + 1 for this functionallity

Again, please use GitHub's reaction button on the top comment to upvote this functionality, which will help us prioritize the issue. Adding "+1" comments causes unnecessary notifications for the developers.

"TypeError: Cannot read property 'signature_time_stamp' of undefined" using the branch of @viveksjain

+1. Waiting for this feature!..

When this functionality will be available? What happened to the progress of viveksjain?

@complience Hi, I have a proof-of-concept working at https://github.com/viveksjain/pdf.js/tree/sig-verify-support. You can try it by using git clone --recursive https://github.com/viveksjain/pdf.js.git. With a little bit more work it Should be ready for a pull request into esta repo, but I just Have not Had the time yet.

@lexcorp Unfortunately this became a lower priority for me after my previous message. I'll see if I can get around to it, but not going to make any promises I can't keep…

I'm trying to compile this version: https://github.com/viveksjain/pdf.js/tree/sig-verify-support
When I enter the command: node make generic
I get the message: ### Getting extension build number
And the compilation process is not performed

How I can resolve this error?
I am doing something wrong?
Why not end the compilation? unfortunately the console does not send me more information to solve

@lexcorp If there's still any interest, at least my version is updated enough to compile. :+1:

Hi Vivek, yes I´m still interest, thank you...

2016-12-12 12:55 GMT-06:00 Gustavo Zambonin notifications@github.com:

@lexcorp https://github.com/lexcorp If there's still any interest, at
least my version is updated enough to compile. 👍


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/mozilla/pdf.js/issues/1076#issuecomment-266518165,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFfB-LbmIVIrJLnxwJlm8aDITDKh5tWLks5rHZi5gaJpZM4BlvMP
.

Hey Gustavo, thanks...

2016-12-12 12:55 GMT-06:00 Gustavo Zambonin notifications@github.com:

@lexcorp https://github.com/lexcorp If there's still any interest, at
least my version is updated enough to compile. 👍


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/mozilla/pdf.js/issues/1076#issuecomment-266518165,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFfB-LbmIVIrJLnxwJlm8aDITDKh5tWLks5rHZi5gaJpZM4BlvMP
.

is there an issue to why the support for digital signatures does not get pulled into pdf.js?

Please follow the discussion in #7702.

I am interested in hearing from people about their use cases for signature verification in PDFjs. Please email me at ryan at peculiarventures.com with your use case.

I would also be interested in hearing your use cases for signing in PDFjs, if you care about that scenario I would also want to hear your use case.

The sig-verify-support branch of pdf.js does not support IE and firefox perfectly cause WebCrypto can not be get, any idea to deal with it?

Hi folks - Is digital signature verification already working?

Same question here: Are digital signatures supposed to work with the latest stable build which can be downloaded from https://mozilla.github.io/pdf.js/getting_started/#download ?

FWIW: I've tested the currently available beta release and can't see any signatures. The only thing I notice is the following line in the browser console:

Warning: Unimplemented widget field type "Sig", falling back to base field type

No, digital signatures are not implemented yet. Anyone who is willing to work on this is welcome to submit a pull request. Thanks.

I want work on this functionality. Someone can give me some guidelines about internal components of PDF.js?

There is some initial work mentioned above that you may be able to use. Make sure to read the wiki for code style and testing instructions.

@wolvz : hi which part in viewer.js would that uncomment be? your repository looks to be the original source for pdf.js

most users though would use the stable version files.

As Adobe Acrobat plugin will be obsolete when Mozilla Firefox 59 ESR will be released, features like displaying digital signatures are now really required in pdf.js for enterprise users.

We have implemented a digital signature solution based on PKIjs and PDFjs that is capable of verifying and creating digital signatures. You can see an example of it viewing the US Digital Signature law here.

image

The viewer currently trusts the CAs on the eIDAS Trust List as well the Mozilla trusted S/MIME issuers.

If you encounter any issues email me at [email protected] with sample files if any.

@rmhrisk can you provide a github repo with a sample code?

@xrkolovos the large majority of the work necessary to make signing and verifying work has been open sourced; it includes https://github.com/PeculiarVentures/PKI.js, https://github.com/PeculiarVentures/ASN1.js, https://github.com/PeculiarVentures/xadesjs/, https://github.com/PeculiarVentures/tl-create, and https://github.com/PeculiarVentures/webcrypto-liner.

We also ended up creating our own PDF library (though we use PDFjs for rendering) so we can create the many different types of signatures PDF allows for. This library will eventually be made public but its not ready for public consumption at this point.

The source to our viewer won't be made public but with the above libraries someone could reproduce verification in their own viewers. We have a basic example of how to do this here: https://pkijs.org/examples/PDFexample.html it would just need to be integrated into your viewers.

when will it be merged with pdf.js ?

@Aarbel at this point I don't know when we will find the time to refactor what we have so it could be easily be merged but we would like to see verify finding itself in PDFjs. With that said the PDFjs team has previously expressed concern over the size this feature would represent due to the necessary dependencies. As long as this is a concern it won't make sense to spend the engineering time to do this work.

IMHO, not implementing it before Firefox 59 (ESR) is released would mean the end of Firefox in enterprise if Chrome or Edge can read digital signatures.

@FrenchHope neither chrome of firefox can verify digital signatures.

Any update on this functionality?

@Snuffleupagus @yurydelendik @timvandermeij ? :)

As I explained in https://github.com/mozilla/pdf.js/pull/7702#pullrequestreview-4866355, first step will be to create an abstract API that allow to integrate any custom PKI/crypto with PDF.js.

@rmhrisk I dont care about Chrome users. I care about Firefox entreprise users. Many will now use Edge browser or Internet Explorer if Firefox cannot anymore verify digital signatures with Adobe Acrobat Reader plugin.

Many companies migrate to Windows 10 now...

Neither can Edge or IE.

@rmhrisk IE can, with Adobe Acrobat Reader ActiveX.

edit : Edge can display the digital signature but does not inform you of the validity of the signature as Adobe Acrobat Reader does.

ActiveX has been deprecated and will eventually not work.

Edge Does not snow the digital signature it shows the image in an annotation regardless of the status of the signature.

Hello, what is the current status of this feature?

It's not being worked on right now, but recently someone showed interest in the code above on IRC. The first step would really be https://github.com/mozilla/pdf.js/issues/1076#issuecomment-374244765.

Hi, do you have any expected date like Dic 2018 or maybe 2019 to release that API?
Thanks for the pdf viewer by the way, works excellent

I wanted to implement the simple fix that was mentioned above... Commenting out the following lines:

// Hide signatures because we cannot validate them.
          if (data.fieldType === 'Sig') {
              _this2.setFlags(AnnotationFlag.HIDDEN);
          }

However, this is causing an error in the console (from util.js:418). Does anyone know what causes this issue (Other than the fact that the signature is now displayed)?

Error:

Uncaught (in promise) DOMException: Failed to execute 'postMessage' on 'DedicatedWorkerGlobalScope': function nonSerializableClosure() {
          return nonSerializable; // creating closure on some variable
        } could not be cloned.
    at eval (http://localhost:8888/src/shared/util.js:418:20)

@brianholle
I tried and if you comment out

 if (data.fieldType === 'Sig') {
      warn('unimplemented annotation type: Widget signature');
     // this.setFlags(AnnotationFlag.HIDDEN);
    }

in built pdf.worker.js, then it works.

It would be nice to at least provide option for this. In our case for example, we already know that signature is valid, because we validate signatures before.

@strazovan Thanks, and agreed. I created a flag that can be set in default_preferences.json. I can post those changes if you are interested!

@brianholle Hello, I'll follow your example. Annotated with this code, chrome displays normally, but the digitally signed image in IE browser obscures the text.

@hanxiaodao You are saying that when commenting out the blocking code:

 if (data.fieldType === 'Sig') {
      warn('unimplemented annotation type: Widget signature');
      // this.setFlags(AnnotationFlag.HIDDEN);
 }

You have issues displaying in IE?

@brianholle Thank you for your reply. I follow your example,but there was a problem in IE 11. The red chapter of digital signature obscures the text content.
This is the effect on chrome.
chrome pic
This is the effect on IE11.
ie11_pic

Can we get any estimations from maintainers if any efforts will be put into signatures verification?

It's not a priority for us right now, but if anyone wants to contribute this (see the comments above for how it should be implemented), then we are willing to look into integrating this in PDF.js.

We are also interested in showing digital signatures which can not be verified. Please, see an example attachted.
Verpf-Erklärg-Bundesdatenschutz-Sig.pdf

when I comment:
if (data.fieldType === 'Sig') {
// this.setFlags(AnnotationFlag.HIDDEN);
}

error:

message_handler.js:87 Uncaught (in promise) DOMException: Failed to execute 'postMessage' on 'DedicatedWorkerGlobalScope': #<DedicatedWorkerGlobalScope> could not be cloned.
    at eval (http://localhost:8888/src/shared/message_handler.js:87:21)

and why don't render the "div. annotationLayer"

Hahaa , I know this one ... it's related to #10350 . So you need to comment this line:
// this.setFlags(AnnotationFlag.HIDDEN);
and add this line after that:
data.fieldValue = null;

How to config the pdf or pdf_viewer to enable the util.js that control the seal displayed switch? There are some AnnotationFlag options in util.js file like INVISIBLE 0x01、HIDDEN 0x02. I modify the AnnotionFlag in pdf.worker.js from HIDDEN to PRINT. Can I config them without this way?

Should be a very nice feature. Hopefully this would be a feature soon!

Anyone knows any reliable workaround to this? Editing built files might only work locally or for testing purposes but no more than that.

Is pdfjs a dead project? Why they don't implement for so many years the most wanted features??

image

I want to achieve that I can show a small notification somewhere in PDF.js that the digital signatures are not validated. I get that working on Chrome, but not on the other browsers. It's far from the best case, but we really want to show those signatures even if they're not 100% validated. I've tried to change the pdf.worker.js code at the piece where this.setFlags(AnnotationFlag.HIDDEN); stood. I've added a "document.getElementbyId" construction where I show my container when there is 1 or more signatures. But all the browsers (except chrome) don't recognize "document". Is there an option to add a property on the document or something, and use that in the viewer.js? There are more constructions with getElementbyId. Any help would be awesome.

We recently wrapped our viewer that supports signature verification into a web component and iframe; you can find out more about how to use it here: https://verify.ink/

rmhrisk that’s great!!!

@brianholle Thank you for your reply. I follow your example,but there was a problem in IE 11. The red chapter of digital signature obscures the text content.
This is the effect on chrome.
chrome pic
This is the effect on IE11.
ie11_pic
I have the same question in IE, have you solved this?

Our organization is consisted by more than 2000 people. All of them are using Chrome, not Firefox because Firefox can't display PDFs' signatures correctly.
I think this should be a priority for Mozilla.

@wolvz: Any progress on your side?

+1

+1

We recently wrapped our viewer that supports signature verification into a web component and iframe; you can find out more about how to use it here: https://verify.ink/

@rmhrisk
Ryan, have you considered opening a version of this visualizer to the community?

We have implemented a digital signature solution based on PKIjs and PDFjs that is capable of verifying and creating digital signatures. You can see an example of it viewing the US Digital Signature law here.

image

The viewer currently trusts the CAs on the eIDAS Trust List as well the Mozilla trusted S/MIME issuers.

If you encounter any issues email me at [email protected] with sample files if any.

@rmhrisk
Ryan, have you considered opening a version of this visualizer to the community?

@lexcorp we made https:/verify.ink so you can easily embed our viewer was a web component.

Adding it is easy:

<html>
  <body>
    <verify-viewer  url="https://verify.ink/assets/documents/electronic_records_and_signatures_in_commerce.pdf"  show-signature-if-present="true"  notify-if-not-signed="true"  sign="true"  download="true"></verify-viewer><script type="module" src="https://verify.ink/webcomponent/index.js"></script>
    </body>
</html>

We recently added support for custom root stores also:
https://verify.ink/guides#root-certificates

From the various threads related do digital signatures, I got the impression that the main reason for the missing progress is that it is not able to verify signatures as a precondition for displaying them.

Would it make sense to distinguish the two use cases "Verify signature" and "Display signature"?

I think there are a lot of use cases where the display of even unverified signatures (if required with a warning added by the specific project team) is all that is required and sufficient. If this is already possible with minor modifications of the code, why isn't that an official functionality that can be switched on or off?

The problem with displaying the signature if it is invalid is that you give users the impression it is valid.

Digital signatures, unlike their synthetic wet counterparts, are intended to denote both authenticity of a signature and the intent associated with it.

By displaying the signature image without validating it you are suggesting to the user it is authentic when it could be just a copy of an image.

But not all valid digital signatures will have a visual representation in a PDF, right? PDF also allows to sign without a visual representation as far as I know.

Shouldn‘t the user of the library decide whether his application/use case allows display of valid/invalid signatures or if additional measures are required like warnings? One use case I have in mind is marking regions in PDFs while considering also signature regions. It can still be of an informative character although other tools are required for final validation. I don‘t see the disadvantage of offering display as an optional feature.

But not all valid digital signatures will have a visual representation in a PDF, right? PDF also allows to sign without a visual representation as far as I know.

Both statements are correct 1) not all PDFs contain a visual representation (most do though). 2) PDF does allow a document wide signature. In this bug, however, what I have seen is interest in showing the visual signature associated with a digital signature and not a document wide signature.

There could be another bug to file for document wide signature support which has no visual representation but I do not recall a single request for this in any of the PDFjs related bugs that exist on digital signatures.

Shouldn‘t the user of the library decide whether his application/use case allows display of valid/invalid signatures or if additional measures are required like warnings?
I personally believe an application developer should be able to choose to do whatever they want with their application.

However, there is also the question of what should a library like PDF.js choose to do also. In my opinion, exposing an option that is insecure, easily misunderstood, and will result in bad security outcomes for the ultimate end-user of the library is not something that library producers should make easy.

Imagine if this feature were complete it would have been of great help during this quarantine by COVID-19, imagine how many transactions, contracts, etc.

They could have been carried out from home, however I have witnessed that this functionality has been stagnant for years, I do not know the reason but I consider that in combination with other tools it could be of great help for collaborative work, home office, etc.

I totally agree. Digital signatures will become more and more of great value in the coming years. My use case is a tool used in medical device development. Without digital signatures our daily work from home office would be really much more difficult. That’s the reason why I would leave it to the project using the library to find a trade-off between risks and customer value or to take additional measures that are appropriate for their specific use case.

I also totally agree that digital signature is indeed a big missing feature.

However, there is also the question of what should a library like PDF.js choose to do also. In my opinion, exposing an option that is insecure, easily misunderstood, and will result in bad security outcomes for the ultimate end-user of the library is not something that library producers should make easy.

The library is implemented by developers, which should be aware of security.
On my part, if a I had the feature, I'll of course display the signature but also check & validate the signature server side so that I can show a warning if the signature is not valid.

@rmhrisk
Do you plan to open source to community ? Because I don't have a single case where I could 1/ Allow docs to be available on internet 2/ Allow a third party to access docs 3/ Allow a 3rd party to inject javascript in user browser.
That would be a great addition to pdfjs.

@rmhrisk
Do you plan to open source to community ? Because I don't have a single case where I could 1/ Allow docs to be available on internet 2/ Allow a third party to access docs 3/ Allow a 3rd party to inject javascript in user browser.
That would be a great addition to pdfjs.

We open-source every libraries we used to create our viewer, and there is a lot of them and many are quite complicated; For example look at PKIjs piece that handles certificate validation for the viewer. We also offer commercial licenses with support.

We will not be open-sourcing the viewer, making this work took a significant amount of time and investment and that time has value. We are happy to support others in using the open-source libraries we created to make this possible though.

Re: 1; the viewer doesn't require docs to be on the internet.

Re: 2; the viewer doesn't require letting a third-party access the docs.

Re: 3; it is possible to host the web component so you can review and control updates to the component.

I also totally agree that digital signature is indeed a big missing feature.

However, there is also the question of what should a library like PDF.js choose to do also. In my opinion, exposing an option that is insecure, easily misunderstood, and will result in bad security outcomes for the ultimate end-user of the library is not something that library producers should make easy.

The library is implemented by developers, which _should_ be aware of security.
On my part, if a I had the feature, I'll of course display the signature but also check & validate the signature server side so that I can show a warning if the signature is not valid.

"Should be" and "are" are two different things. Displaying the signature image when the signature is invalid or untrusted is a great example of the kind of decision someone might make without fully understanding the consequences.

Imagine if this feature were complete it would have been of great help during this quarantine by COVID-19, imagine how many transactions, contracts, etc.

They could have been carried out from home, however I have witnessed that this functionality has been stagnant for years, I do not know the reason but I consider that in combination with other tools it could be of great help for collaborative work, home office, etc.

I totally agree this is why we created and open-sourced all the libraries that made our viewer possible. It is also why we let people use our viewer for free.

Thanks to the work we have done someone could certainly re-create the viewer work we did with far less effort and submit the associated PRs to PDFjs, we would even be happy to code review those PRs.

I need to display pdfs in my Angular CLI app, in a context where the validity of the signature isn't relevant, and the only important part is to have an accurate display.
My test case was the sample pdf with a digital signature from Adobe.
As I've tried many answers already, I will condense the results of my researchs below.

The most common answer I've seen is to comment the following lines in pdf.worker.js (lines 48353 to 48355):

if (data.fieldType === 'Sig') {
      //this.setFlags(AnnotationFlag.HIDDEN);
 }

This, however, didn't work.

Commenting the following lines in annotation.js directly in pdfjs-dist didn't work either (lines 285 to 287):

case 0:
        this.color = null;
        break;

This didn't work either, even though I didn't know how to place line of code given:
(<any>window).pdfWorkerSrc = '<path_to_file>/pdf.worker.js';

I have tried to at least get the annotations in the page, but every page returned an empty array:

page.getAnnotations().then(function(annotations) {
     console.log('annotations loaded');
     console.log(annotations);
     for (let i = 0; i < annotations.length; i++) {
          console.log(annotations[i].subtype);
      }
 }, function (reason) {
     console.log(reason);
}); 

It is important for my app to display the pdf as is. At the very least, I would like to be able to get the bounding rectangles of the signature to display a placeholder in their stead.
Could anybody help me ?

I need to display pdfs in my Angular CLI app, in a context where the validity of the signature isn't relevant, and the only important part is to have an accurate display.
My test case was the sample pdf with a digital signature from Adobe.
As I've tried many answers already, I will condense the results of my researchs below.

Hi, I think you almost had it with your first try ... have you tried this https://github.com/mozilla/pdf.js/issues/1076#issuecomment-446959325 ?

I just tried it : nothing changed.
Any other idea?

This issue has been opened for quite some time now, what is the current plan for tackling it, and how can we help?

If I cannot display the signature, at the very least, I would like to display a placeholder rectangle where it should be.
(Simply knowing the x,y coordinates as well as the width and length of the signature)

Of course, displaying the signature would still be the best scenario (once again, I don't need to verify it in my specific use case).

Would it be an option to add a render option for displaying the unverified signatures?
This way the users of pdf.js could decide if they want to take the risk of displaying them or not.

Displaying a invalidated cryptographic signature is as bad as displaying one that is incorrectly validated:
https://www.pdf-insecurity.org/

What if the signature has been validated correctly before by lets say a backend-service?
This would mean that the signature was OK but still could not be displayed in a client-application.

A render option to display the signature or not would enable users of pdf.js to validate the signature somehow and then decide on their own to display it or not.
It would also remove the burden from the developers of pdf.js developers to provide signature verification at all as this should probably not be part of pdf a rendering library.
Strictly not displaying the signature at all limits the use-cases of pdf.js.

What if the signature has been validated correctly before by lets say a backend-service?
This would mean that the signature was OK but still could not be displayed in a client-application.

A render option to display the signature or not would enable users of pdf.js to validate the signature somehow and then decide on their own to display it or not.
It would also remove the burden from the developers of pdf.js developers to provide signature verification at all as this should probably not be part of pdf a rendering library.
Strictly not displaying the signature at all limits the use-cases of pdf.js.

Doing the validation between server and client is fine. Exposing a flag to display the signature as valid and validated would be a foot gun.

Doing the validation between server and client is fine. Exposing a flag to display the signature as valid and validated would be a foot gun.

We are dealing with verified signatures but cannot display them (without hacking) in the clients browser using pdf.js
So what other option to render PDFs in the clients browser would you suggest to render the visual representation of the verified signature?

You can patch your PDFjs prior to deployment to have whatever behavior you need?

That's what I meant by "hacking" and that's exactly what we are currently forced to do :-(

I don't see why we are still asking questions about the issue itself: the "hacks" didn't even work for me, and I'm still in the need.

In my use case, the validity of the signatures are not in question. However, I need to display them, or at least let the user know that there is "something there" instead of just that blank part of the canvas.
I don't care if the API comes with a huge red warning paragraph about unverified signatures, or if it forces me legally to say it can't be verified, or if it warns me that it is at my own risks.
...I just need to display the signature.

At the very least, I'd really want to have the position and size of the signatures on the document, so that I can display a gray box in their place with "hey, user, there is supposed to be a signature there" written on them.

Currently, the user doesn't have the ability to know that the document is signed at this spot.
Isn't that an even worse way of tempering?

If there was a boolean that allowed to display all digital signatures of the document as transparent gray template boxes, that would be satisfying enough, and that feature wouldn't raise any ethic/security problem.

(I'd also like to say that the problem has apparently been pending since 2012 with more than a hundred comment, in this thread alone. I don't think I am the only one waiting for this feature)

Gray boxes would rather seem like a rendering error and very likely overload a provided support-hotline :-)
We have a working hack in place, that works fine for now but is admittedly very ugly:

  1. Download the current, transpiled and minified version of pdfjs-dist
  2. Patch the lines in question in the transpiled version.
  3. Release as new private package to internal npm-repo.
  4. Use patched package instead of original pdfjs-dist package.

Ugliy right? But it works and renders the embedded signatures just fine.

Gray boxes would rather seem like a rendering error and very likely overload a provided support-hotline :-)

Yes, yes, yes, I meant any template/image/message that could be complimented by *the pdf contains digital signatures that couldn't be verified, and as such, were not displayed. Anything that could be understood by the user if a message explained it.

  1. Patch the lines in question in the transpiled version.

I'm currently using Angular CLI with pdfjs-dist installed in my node_modules, but any solution that I've written a few posts ago didn't work on my side, and neither did this:

Hi, I think you almost had it with your first try ... have you tried this #1076 (comment) ?

Did I miss something, or is my case too specific for that fix?

We followed the explanation in this thread.
https://github.com/mozilla/pdf.js/issues/4743#issuecomment-163953288

We basically changed this part:

// Hide unsupported Widget signatures.
if (data.fieldType === 'Sig') {
   warn('unimplemented annotation type: Widget signature');
   this.setFlags(AnnotationFlag.HIDDEN);
}

To this:

// Hide unsupported Widget signatures.
if (data.fieldType === 'Sig') {
   warn('unimplemented annotation type: Widget signature');
}

I know you could remove the whole 'if' but we wanted the smallest possible patch.

Yikes. That is indeed the fix that didn't work on my side.
I'll try again when I go back to the pdf displaying part of my app.
I didn't create my own package yet, but changing the file directly in node_modules/pdfjs-dist didn't change anything last time I tried.

Did you change both files pdf.worker.js and pdf.worker.min.js
This was necessary in our approach.

Did you change both files pdf.worker.js and pdf.worker.min.js
This was necessary in our approach.

You raise an excellent point that I may have overlooked !
I'll try that quickly today, and see if it works.

Hi I like your approach, but unfortunately it didnt work for me
I changed the lines like this:

We followed the explanation in this thread.
#4743 (comment)

We basically changed this part:

// Hide unsupported Widget signatures.
if (data.fieldType === 'Sig') {
   warn('unimplemented annotation type: Widget signature');
   this.setFlags(AnnotationFlag.HIDDEN);
}

To this:

// Hide unsupported Widget signatures.
if (data.fieldType === 'Sig') {
   warn('unimplemented annotation type: Widget signature');
}

I know you could remove the whole 'if' but we wanted the smallest possible patch.

Then I built it with gulp generic and used the built resources.

Did you change both files pdf.worker.js and pdf.worker.min.js
This was necessary in our approach.

The pdf.worker.js was built but you mention pdf.worker.min.js, how is that built and where is it stored?
What am I missing?

Thanks a lot in advance

@ll-priva We didn't build pdf.js ourselves.
Like I said in Comment https://github.com/mozilla/pdf.js/issues/1076#issuecomment-658601553 we actually downloaded the already built version of pdfjs-dist and patched the bundled versions of pdf.worker.js and pdf.worker.min.js.

My explanation in https://github.com/mozilla/pdf.js/issues/1076#issuecomment-658609803 was probably a bit unclear, sorry.
We implemented the described solution by patching the prebuilt package https://www.npmjs.com/package/pdfjs-dist.
Then we used these patched versions of pdf.worker.js and pdf.worker.min.js to push a private pdfjs-dist package to our internal npm-repository.
Last but not least we used this patched version in our production code instead of the official pdfjs-dist package.

I hope this makes our approach a bit clearer.

@PSpSynedra Thank you very much. That worked for me as well

I'm back on this task for the first time in a few weeks, but it still doesn't work on my side.
I haven't made my own private package for the moment : as long as I didn't rebuild, modifying directly the files in node_modulespdfjs-dist should have worked (locally, then I would have to indeed import the modified pdf.js as an asset or package).

Searching "Sig" in the folder gives 4 different file results :

  • pdfjs-dist\buildpdf.worker.js
  • pdfjs-dist\buildpdf.worker.min.js
  • pdfjs-dist\es5\buildpdf.worker.js
  • pdfjs-dist\lib\core\annotation.js

I edited all of those 4 occurences to remove the content of the "if" which cleared the signature field and set a flag to hide it, as mentioned above.
Nothing different happened : getAnnotations() returns an empty array, and the existing signatures are still not displayed.

I also still get this message in the console, which is not even an error or warn (pdf.worker.js:2965:14) :

Warning: Unimplemented widget field type "Sig", falling back to base field type.

By looking at the code, it means annotation.js wraps it in a "base" WidgetAnnotation, which means the message doesn't appear to be a problem, only the flags that I removed.

Am I missing something? I edited the min.js file as well as the js file, which are in the build folder and as such should be the ones used, so everything should have worked...
What exactly did you do @ll-priva and @PSpSynedra ?

@Epsiom this is what I just did, and it worked for me in about 5 minutes: https://github.com/mozilla/pdf.js/issues/1076#issuecomment-446959325

You need to both comment out the this.setFlags(AnnotationFlag.HIDDEN); as well as add data.fieldValue=null. The only file I modified was pdf.worker.js, which in our case is from the pdfjs-dist library so is minified already

@Epsiom and others that may end up here.
I had the same issue, edited pdf worker files to no result.

In my case I am using https://github.com/VadimDez/ng2-pdf-viewer to display pdf in an angular app. This module was directly loading pdf worker from cloudflare, not local file. So check if the web app is really using the modified pdf.worker.js file. You can check by clicking in the Unimplemented widget field type "Sig" warning in the console and move the mouse to the file name.

@konum The warning is from "http://localhost:4200/assets/vendor/pdf.worker.js", but I already commented out the two lines of this file as told before:
if (data.fieldType === 'Sig') { //this.setFlags(AnnotationFlag.HIDDEN); //data.fieldValue = null; }

Still no digital signature in sight...

@Epsiom Didn't work for me either. Still looking into it.

@Epsiom Managed to get the signature to view. In pdf.worker.js add this on line 18480
case "Sig":
return new SquareAnnotation(parameters);

Is the switch just above this line.
(0, _util.warn)('Unimplemented widget field type "' + fieldType + '", ' + "falling back to base field type.");

@konum Didn't work for me :
ERROR Error: Uncaught (in promise): Object: {"message":"SquareAnnotation is not defined","stack":"AnnotationFactory_create@http://localhost:4200/assets/vendor/pdf.worker.js:47999:7\nget annotations@http://localhost:4200/assets/vendor/pdf.worker.js:48877:43\nLocalPdfManager_ensure/<@http://localhost:4200/assets/vendor/pdf.worker.js:49204:21\nLocalPdfManager_ensure@http://localhost:4200/assets/vendor/pdf.worker.js:49202:14\nPage_getOperatorList@http://localhost:4200/assets/vendor/pdf.worker.js:48815:43\nwphSetupRenderPage/<@http://localhost:4200/assets/vendor/pdf.worker.js:49883:13\n"} AnnotationFactory_create@http://localhost:4200/assets/vendor/pdf.worker.js:47999:7 get annotations@http://localhost:4200/assets/vendor/pdf.worker.js:48877:43 LocalPdfManager_ensure/<@http://localhost:4200/assets/vendor/pdf.worker.js:49204:21 LocalPdfManager_ensure@http://localhost:4200/assets/vendor/pdf.worker.js:49202:14 Page_getOperatorList@http://localhost:4200/assets/vendor/pdf.worker.js:48815:43 wphSetupRenderPage/<@http://localhost:4200/assets/vendor/pdf.worker.js:49883:13

@Epsiom Are you using latest version of pdf.js? in pdf.worker.js there should be SquareAnnotation class defined.

@Epsiom just to clarify, only this.setFlags(AnnotationFlag.HIDDEN); should be commented. data.fieldValue = null; should be added if its not present, but should NOT be commented.

We are also using the pdfjs-dist package, so we modified that one directly, as per an earlier comment. Are you positive that the code you are modifying is actually being executed? If it's in node_modules, depending on your build, some of those assets might be cached, and you might not actually be using your modified code.

@kjhangiani I clearly remember having any added console.log show up in the console, so it is clearly executed.
I'll try to add data.fieldValue = null; when I come back to this task, and see if that works.

Adding data.fieldValue = null; back in the if (data.fieldType === 'Sig') block, as well as a console.log("TEST") just in case, and nothing happened, while "TEST" correctly appeared in the console, after the usual Warning: Unimplemented widget field type "Sig", falling back to base field type. message.

Any other idea?

@Epsiom Managed to get the signature to view. In pdf.worker.js add this on line 18480
case "Sig":
return new SquareAnnotation(parameters);

Is the switch just above this line.
(0, _util.warn)('Unimplemented widget field type "' + fieldType + '", ' + "falling back to base field type.");

That worked for me, you saved my day, thank you.

@yduybya How recent is your project ?
Is there any particularity about it ?
I think I need to update my version of pdf.js and try it again, even though it is pretty recent.

Is there any easy way to update pdf.js on an Angular 9 app ?
I found the new pdf.worker.js here (http://mozilla.github.io/pdf.js/build/pdf.worker.js), but only replacing that file didn't work (obviously).

I traced my project back to https://github.com/mozilla/pdf.js/issues/8836 and https://github.com/ashishyadav0019/pdfJS_angular4_Ts.git, but these projects are using outdated files.

The files on the pdf.js github and on pdfJS_angular4_Ts.git are not correlated.
Does anybody know how to correctly import pdf.js on an Angular 9 project, with up-to-date files ?

@Epsiom For Angular 8 app )I think it should work on angular 9) I am using https://github.com/VadimDez/ng2-pdf-viewer.

From ng2-pdf-viewer docs:
By default the worker is loaded from cdnjs.cloudflare.com.
In your code update path to the worker to be for example /pdf.worker.js
(window as any).pdfWorkerSrc = '/pdf.worker.js';
This should be set before pdf-viewer component is rendered.

Using this project will add the pdfjs-dist dependency to your project. Edit the node_modules/pdfjs-dist/build/pdf.worker.js with the squareAnnotation tip.

@konum I'm using pdf.js directly and not ng2-pdf-viewer for multiple reasons, by getting inspired by this: https://github.com/ashishyadav0019/pdfJS_angular4_Ts.git
I have the pdfjs-dist dependency, but it's the src/assets/vendor/pdf.worker.js that is used.
Any idea ?

@Epsiom Have you tried updating both pdf.js and pdf.worker.js files to latest code?

@konum That is precisely what I am trying to do, but since pdf.js is rarely used in Angular, as most project seemingly only need ng2-pdf-viewer, and since the files used in the latest version of pdf.js are different, the process of doing so is far from obvious at first glance.

Hello,

Commenting this.setFlags(AnnotationFlag.HIDDEN); in pdf.worker.js at v2.6.347 not show the signature image.

Was there a change in that?

@lainosantos Yes, there's a change. If you deactivate form rendering, the signatures are shown again.

@stephanrauh Thanks.

PDFViewerApplicationOptions.set('renderInteractiveForms', false);

Is there a way to enable forms and show signatures?

@lainosantos No, but I've found a nice walk-through how to build your own forms. The example assumes that renderInteractiveForms is dectivated. It uses Angular, but I guess you can extract the idea even if you're using a different framework: https://medium.com/factory-mind/angular-pdf-forms-fa72b15c3fbd

I have more urgent matters for the moment and cannot spend time on the task, but if anyone manages to import an up-to-date pdf.js version on Angular 9, he would have my deepest thanks.

@Epsiom Here you are: https://www.npmjs.com/package/ngx-extended-pdf-viewer :)

@stephanrauh ...Well, except that I need to be compatible IE11 and only use the canvas directly to have a custom-made pdf viewer, so I cannot use that, sadly.
I cannot use ng2-pdf-viewer either, or anything of the sort, I am really asking about pdf.js in itself, which is a really niche case.

Was this page helpful?
5 / 5 - 1 ratings

Related issues

xingxiaoyiyio picture xingxiaoyiyio  ·  3Comments

AlexP3 picture AlexP3  ·  3Comments

smit-modi picture smit-modi  ·  3Comments

jigskpatel picture jigskpatel  ·  3Comments

aaronshaf picture aaronshaf  ·  3Comments