This has unwanted effects when you try to fill german pdf forms. htmlspecialchars breaks umlauts and pdftk can't find the right field for filling in data. Maybe other languages are problematic as well.

CommentFileSizeAuthor
#6 fillpdf_1904100_create_xfdf.patch2.36 KBliam morland
#4 xfdf.diff1.15 KBHalim_61
#3 pdftk.txt99 bytesHalim_61
#2 xfdf-working.txt109 bytesHalim_61
#2 xfdf-broken.txt113 bytesHalim_61
#2 pdftk.txt3.69 KBHalim_61

Comments

wizonesolutions’s picture

wizonesolutions
he/him
Primary language English
Location Norway
commented
Version: 7.x-1.9 » 7.x-1.x-dev
Priority: Critical » Normal
Status: Active » Postponed (maintainer needs more info)

Thanks for reporting this. If you submit a patch that doesn't introduce security issues, I will consider it. Documentation: http://drupal.org/patch/create

I am also downgrading this to normal because:

  1. This code has been in a place for a really long time, and no one has reported this yet.
  2. You didn't provide a concrete example.

I will still try to reply quickly if you come back with a patch.

Halim_61’s picture

Halim_61 commented
StatusFileSize
new pdftk.txt3.69 KB
new xfdf-broken.txt113 bytes
new xfdf-working.txt109 bytes

The code could be there for a long time but it can't be used with pdf files which contains umlauts in pdf-fieldnames. The attachments demonstrates it.
Filtering special html chars in userinput is important because of security reasons but in this case xfdf.inc you replace eg.: & chars with amp. pdftk can't file in the formdata because of changed Fieldname.
The fieldnames were read from pdf file. It's not a user input which must be parsed.
Please have a look to attached files.

The patch would be removing htmlspecialchars in xfdf.inc completely.

Halim_61’s picture

Halim_61 commented
StatusFileSize
new pdftk.txt99 bytes
Halim_61’s picture

Halim_61 commented
StatusFileSize
new xfdf.diff1.15 KB

Here is my proposed patch.
It works as follows:
- defines two array with german umlauts and the htmltags like ò etc
- checks for correct encoding utf-8
- replaces specialchars with correct utf-8 encoded umlauts
- Last it uses htmlspecialchar function like before!
Thx a lot for your work on fillpdf!

wizonesolutions’s picture

wizonesolutions
he/him
Primary language English
Location Norway
commented
Status: Postponed (maintainer needs more info) » Needs work

Thanks for the patch. I think that, as you said, we should just avoid htmlspecialchars(). I don't want to fix things only for a specific language.

The risk here will be that people with the ability to upload PDFs might be able to do something with the field names, although it's rather unlikely. Therefore, the patch should make the Administer Fill PDF permission display the security warning, just so people will know of the remote risk.

If I have time, I will look into this, but again, patches speed things up :)

liam morland’s picture

liam morland
Primary language English
Location Ontario, CA 🇨🇦
commented
Status: Needs work » Needs review
StatusFileSize
new fillpdf_1904100_create_xfdf.patch2.36 KB

Here is a patch which rewrites create_xfdf() to use DOMDocument. This should guarantee well-formed XML and does not make use of htmlspecialchars().

wizonesolutions’s picture

wizonesolutions
he/him
Primary language English
Location Norway
commented

Thanks a lot Liam. I know someone who needs this and pointed them here. It should get some testing soon.

This one looks like it'll be 7.x-1.x-dev specifically, but I should cross-port it to PDF Forms API when I restore pdftk functionality there.

cphilli12’s picture

cphilli12 commented

I am not sure if this was intended to be applied then it will just work..... I have an issue That is affecting my PDF reports, I am seeing " instead of ".

I applied the patch, and ran the FIll PDF, and it still displayed " instead of "....

Was this supposed to work for " (quotes) ?

[Heine - Added code tags around HTML entities]

liam morland’s picture

liam morland
Primary language English
Location Ontario, CA 🇨🇦
commented

Things should work the same before and after this patch. This is a more robust way of generating XML. In some more rare cases, characters might be escaped differently.

I don't understand what the problem is that you are observing. Are you trying to say that you are seeing " in your output?

cphilli12’s picture

cphilli12 commented

Yes I am seeing " in my ouput...

wizonesolutions’s picture

wizonesolutions
he/him
Primary language English
Location Norway
commented
Priority: Normal » Major
liam morland’s picture

liam morland
Primary language English
Location Ontario, CA 🇨🇦
commented
Title: don't use htmlspecialchars in create_xfdf function » Don't use htmlspecialchars() in create_xfdf()

In my testing with the latest 7.x-1.x-dev, both with and without this patch, I can fill PDF forms with both single and double quotes from Webform without any problems.

I think we need to open another issue for the problem of seeing """ in output.

Is there anything holding up commit of this patch?

liam morland’s picture

liam morland
Primary language English
Location Ontario, CA 🇨🇦
commented
Version: 7.x-1.x-dev » 7.x-2.x-dev
Issue summary: View changes
Status: Needs review » Fixed

http://drupalcode.org/project/fillpdf.git/commitdiff/e3c456f

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.