Error handling when setSignaturePromise() fails

[ThomasRutzer]

Similar to issue #835, it is also difficult to recognise from the client's perspective when a signature request fails. It appears that data is still being sent via the web socket connection here without a traceable error/warning that could be handled in the client.

In our case, we would like to stop the printing process if the signature fails. Does anyone have any tips on how we can achieve this?

[tresf]

Can you create a minimal example?

[ThomasRutzer]

Is there any boilerplate / CodePen with a setup to start from?

[tresf]

Is there any boilerplate / CodePen with a setup to start from?

I sort of asked you for this, but for sake of moving forward with this bug report:
https://jsfiddle.net/mjcqt95p/6/

In our case, we would like to stop the printing process if the signature fails. Does anyone have any tips on how we can achieve this?

This should be the default behavior already. If you change the above example from:

	return (resolve, reject) => {
-         reject("foo");
+         resolve("foo");
	};

... the call should succeed. There's a chance we're not handling the rejection properly, but the default behavior seems to be what's being described in this bug report where the print does not work when the signature fails.

[ThomasRutzer]

Hi @tresf, thanks for your quick reply. Based on your example, if I would extend it with an .catch()–phrase, I'd actually expect it to log the error. But afaik, no error is thrown.

qz.security.setSignaturePromise(toSign => {
    return (resolve, reject) => {
        reject("foo");
    };
});

qz.websocket.connect().then(() => {
    return qz.printers.find();
}).then(printers => {
    console.log(printers);
}).catch(e => {
    console.log("signing error", e)
});

[tresf]

A signature failure is not actionable on the client-side, so it's not -- and has never been part of -- the connecting/printing/API call promise chain. This same statement is true for setCertificatePromise.

qz.security.setCertificatePromise((resolve, reject) => { reject("no"); });

Notice that the API calls do NOT reject.

[tresf]

I understand that this leaves the state of a print job in limbo. Certificates are public, can be provided in clear text and should never fail, so this is less of a concern. Signatures are often handed off to a controller so a failure can be a sign of another issue with the backend system. I'll bring this up to our JS developer to see if there's a way to throw the rejection up the call stack.

Pinging @akberenz.

[ThomasRutzer]

Hi @tresf, thanks again. I'd suggest to leave this issue open then to see if @akberenz can figure something out?

[tresf]

This is available starting now with the snapshot version: https://raw.githubusercontent.com/qzind/tray/master/js/qz-tray.js

This will be released (e.g. to NPM) as qz-tray.js@2.2.4 in coordination with the future 2.2.4 release (probably sometime next week).