qzind / qz-print

Archive for legacy qz-print versions (1.8, 1.9). See https://github.com/qzind/tray for modern versions.
Other
141 stars 101 forks source link

Jetty defaults to non-UTF8 on Windows #147

Closed tresf closed 8 years ago

tresf commented 8 years ago

Some interesting behavior...

  1. Start QZ Tray from IntelliJ, signing works.
  2. Start QZ Tray from installer, signing does not work.

Steps to reproduce

  1. Create a raw message using the 2.0 branch where the data contents contain unicode. e.g.

    var data = [ "€" ];
    qz.print(config, data);
  2. Configure signing (in my case, I configured for POST).
  3. Start QZ Tray from the desktop installer (NOT IntelliJ)
  4. Using a Windows machine load the sample page and try to print the raw UTF8 commands silently.
  5. Observe the warning is displayed.

Background

After several hours of trial and error, a client sent this PHP work-around for instances running from the installer: $req = iconv("UTF-8", "CP1252",$_POST['request']);

This is obviously a terrible solution as it assumes Jetty is interpreting the message as CP1252 as well.

At first I thought we we're missing a Jetty preference... Here's are two related articles: http://stackoverflow.com/a/31854430/3196753 http://stackoverflow.com/questions/4214111/jetty-character-encoding-issue

Workaround

A possible workaround on Windows:

java -jar -Dfile.encoding=UTF8 "%PROGRAMFILES%\QZ Tray\qz-tray.jar"
----------^
akberenz commented 8 years ago

On working with a similar issue caused by plus signs, I came upon a lot of references stating it was common to hash a message before signing it. This will give us a fixed length and prevent issues with special characters. Implemented in aa71578b6de26952145405ba44d0734903d817e7, we hash it with sha-256 browser side before sending to the signing server, and then again on the QZ software for verifying. This means users won't have to hash on their server (unless self-signing), but we do gain another soft requirement (overridable via qz.api.setSha256Type)

akberenz commented 8 years ago

If you can verify that this encoding problem doesn't affect anything else, we can close this issue.

tresf commented 8 years ago

Are we sure this is the correct approach?

If data is making it incorrectly into the WebSocket, that is a problem. Fixing the signature is a bandaid to the underlying problem, no?

@robertcasto opinions welcome here.

tresf commented 8 years ago

P.S. I do like the idea of sending less data to the server.

akberenz commented 8 years ago

I agree, I've added (not yet pushed) an explicit call to UTF-8 on string<->byte conversions, which was likely the issue with signing. But I haven't seen this as an issue elsewhere, ie printing an image called image_€.png works just fine. Without knowing what else is affected (if anything), I cannot fix it properly.

tresf commented 8 years ago

printing an image called image_€.png works just fine

That sounds fishy. This all was through the desktop, not the IDE?

tresf commented 8 years ago

Also, another concern of mine is the byte length for each character. Can we definitively say that CP1252, ISO-8859-1, or whatever's being defaulted here can hold every UTF8 character we can throw at it?

tresf commented 8 years ago

We're already rolling our own stringify (albeit for Prototype compat) Perhaps this... http://stackoverflow.com/a/4901205/3196753

tresf commented 8 years ago

Related #150.

Closing per user feedback, testing and via aa71578, 200eac7.