Open ethanpil opened 2 years ago
@dymosoftware The CORS problem is fixed. But a new fatal error HTTP 400 was returned.
Error printing label. Exception: 'Element' is an invalid XmlNodeType. Line 22, position 4.
I tried the XML of two different .dymo files. Same line error. (Yes I removed the Byte Order Mark.. that's another confirmed bug see issue #45 ).
@dymosoftware The CORS problem is fixed. But a new fatal error HTTP 400 was returned.
Error printing label. Exception: 'Element' is an invalid XmlNodeType. Line 22, position 4.
I tried the XML of two different .dymo files. Same line error. (Yes I removed the Byte Order Mark.. that's another confirmed bug see issue #45 ).
@timint could you attach the payload sent through the PrintLabel request from Network tab? Specially the labelXML value.
@dymosoftware I have created a separate issue ticket for that. See issue #47
@dymosoftware is there a plan to fix the DYMO CONNECT version 1.4.2 on macOS? We're facing an error on macOS Big Sur DYMO Label Plugin is not installed.
Thank you
Hi all, could you try to run your app with this preview version of DLSSidecar_1.4.3-147-beta-WS.exe installed?
Let us know if you still have issues with API headers.
OK with the Beta installed ( and rebooted ) it works fine! Thank you! Do you know at which Version this fix will be included?
Hi all, could you try to run your app with this preview version of DLSSidecar_1.4.3-147-beta-WS.exe installed? Let us know if you still have issues with API headers.
OK with the Beta installed ( and rebooted ) it works fine! Thank you! Do you know at which Version this fix will be included?
Fix will be included in 1.4.3 release, expected on March.
I'm the originator of this issue and I just came back happy to find this closer to being resolved, however it seems the link to DLSSidecar_1.4.3-147-beta-WS.exe is now invalid?
@ethanpil : You can find exe and mac application on this URL Beta Version
I'm the originator of this issue and I just came back happy to find this closer to being resolved, however it seems the link to DLSSidecar_1.4.3-147-beta-WS.exe is now invalid?
@ethanpil You can find DLSSidecar_1.4.3-150-beta-WS here
@dymosoftware it seems that link is not working anymore. It mentions something about LFS quota being reached. Can you please put the EXE somewhere we can download it?
I'm the originator of this issue and I just came back happy to find this closer to being resolved, however it seems the link to DLSSidecar_1.4.3-147-beta-WS.exe is now invalid?
@ethanpil You can find DLSSidecar_1.4.3-150-beta-WS here
I installed this version on one of our client machines (Win7) . It doesnt work at all. The Dymo Connect GUI crashes with this info:
Problem signature: Problem Event Name: CLR20r3 Problem Signature 01: DYMOConnect.exe Problem Signature 02: 1.4.3.150 Problem Signature 03: 61f4072b Problem Signature 04: mscorlib Problem Signature 05: 4.6.1590.0 Problem Signature 06: 5787ed44 Problem Signature 07: 4168 Problem Signature 08: 0 Problem Signature 09: System.Windows.Markup.XamlParse OS Version: 6.1.7601.2.1.0.320.65 Locale ID: 1043 Additional Information 1: 0a9e Additional Information 2: 0a9e372d3b4ad19135b953a78882e789 Additional Information 3: 0a9e Additional Information 4: 0a9e372d3b4ad19135b953a78882e789
And the Connect services crashes too:
On another PC with Win7 it does install succesfully. The CORS issue still occurs though:
mainjs?v=JW3WR4tR-tptGWtItcMMRRypi85OXD4RYaO3umL1AOI1:1 Access to XMLHttpRequest at 'https://127.0.0.1:41951/DYMO/DLS/Printing/GetPrinters' from origin 'XXXXXXXX' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
Seems like the allow-origin is still missing here.
On another PC with Win7 it does install succesfully. The CORS issue still occurs though:
mainjs?v=JW3WR4tR-tptGWtItcMMRRypi85OXD4RYaO3umL1AOI1:1 Access to XMLHttpRequest at 'https://127.0.0.1:41951/DYMO/DLS/Printing/GetPrinters' from origin 'XXXXXXXX' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
Seems like the allow-origin is still missing here.
Is there any news on this? We have been forced to revert back to Chrome 97 (Chromium) for many (100+) of our clients. Which is far from ideal and not future-proof at all.
What's the status on Mac? The lack of any kind of documentation makes this all very confusing, but from what I can tell DYMO Connect doesn't have a web service on Mac, so we're running Dymo Label Service. As of recent Chrome versions it fails CORS checks like everyone is pointing out, but it also completely hangs on certain requests, which, I believe, is due to a CORS preflight request that Chrome issues. The web service takes the connection but never responds, so it just hangs indefinitely.
You can reproduce this with cURL as follows:
curl -H "Origin: https://example.com" -H "Access-Control-Request-Method: GET" -H "Access-Control-Request-Headers: X-Requested-With" -X OPTIONS --verbose https://127.0.0.1:41951/DYMO/DLS/Printing/GetPrinters
Which, instead of getting an XML response and closing the connection, will just sit waiting forever.
Firefox doesn't seem to have this issue (yet) but it's probably only a matter of time before printing with the web service is broken there too.
Stable DCD on Mac is missing Web Service, Beta version has it - but it fails to start properly due to SSL error.
We have to ask people to use --disable-features=PrivateNetworkAccessRespectPreflightResults
flag to be able to use DYMO on Chrome 98 since it does not handle prefligh requests in any of expected ways, it simply keeps connection opened indefinitely and 3000ms timeout on request actually never times out.
Is there documentation for the api endpoints? It seems that would help in narrowing down some issues.
I've read through the entire thread. These are things that don't work:
❌ Printing from DYMO's sample webpages on amazon
❌ Printing from @ande2407 's example webpage
❌ Printing from my own remote web page (yes, with the dymo connect js library directly within my codebase and not using a cdn or external reference)
❌ Disabling Block insecure private network requests
does not fix the issue for a remote requests to localhost
✅ The only fix for me is to run the web app on localhost (which isn't a fix because that's my local dev environment and not available to my users).
✅ I have no issues with my label's xml and no HTTP 500 errors. Everything prints fine from local. I use the exact same label structure and dymo js in code deployed to other servers, so no change there. Additionally, I get the error on any call to the printer webapi including just a status check /DYMO/DLS/Printing/StatusConnected
If we could get some documentation to understand how to form a good request then we could make our own calls to the endpoint. So, if it is Chrome hiding a 500 error for whatever reason at least we could diagnose properly.
The CORS header must be the issue because it just doesn't happen when the code is running from localhost, or from other browsers (and older versions of Chrome). Wouldn't we see issues on local if there were in fact mal-formed label xml or otherwise?
Access to XMLHttpRequest at 'https://localhost:41951/DYMO/DLS/Printing/StatusConnected' from origin '{REMOTE}' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
DYMO just uploaded (4 hours ago) a new version of the DLSSidecar and it works for me. It is version 1.4.3.123-beta.
Yesterday i tried with the DLSSidecar_1.4.3-150-beta-WS.exe and it did not work. I had to uninstall Dymo Connect, before i was able to install the 1.4.3.123 version.
Direct link to the corresponding (?) Mac app, uploaded at the same time: https://github.com/dymosoftware/Beta-Version/blob/main/DYMO%20Connect%20Mac/DYMOConnect-1.4.3.93-beta.pkg
Not in a position to try it out currently.
1.4.3.93 beta on macOS does not work for me. Diagnose gives an error:
Curl shows some kind of SSL error:
curl: (35) error:1400410B:SSL routines:CONNECT_CR_SRVR_HELLO:wrong version number
I get the following error on 1.4.3.93-beta
There is an work-around for the beta version Web Api issue. https://github.com/dymosoftware/Beta-Version/issues/2
There is an work-around for the beta version Web Api issue. dymosoftware/Beta-Version#2
Following @blester-mvc's instructions to remove everything and start from a blank slate worked for me.
Well, the CORS issue has now hit with the latest Firefox update, so the workaround we had of using Firefox instead of Chrome is now dead.
When is this issue going to get resolved? It's been months now!
Running DYMO Connect 1.4.3.103 for Mac
This is in the Firefox console:
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://127.0.0.1:41951/DYMO/DLS/Printing/StatusConnected. (Reason: CORS request did not succeed). Status code: (null).
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://localhost:41951/DYMO/DLS/Printing/StatusConnected. (Reason: CORS request did not succeed). Status code: (null).
Turns out it works in Chrome now, but it's broken in Firefox.
I implemented the Dymo.connect.framework on an in-house PHP/Javascript system in late 2021 and it's been working fine until recently - I presume due to the Firefox updates. We don't use Chrome on any computers.
We too are now getting the CORS error: "Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://127.0.0.1:41951/DYMO/DLS/Printing/StatusConnected. (Reason: CORS request did not succeed). Status code: (null)."
The networking tab in Firefox inspector shows no response, but I presume that's because the failed CORS check completely blocks the response.
I tried to make a copy of the framework with https disabled so that I could do some testing in plaintext (and potentially see error information) but I don't have enough knowledge to do that. The dymo.connect.framework.js file is far more complex than anticipated.
@dymosoftware This issue has been ongoing for a year soon. We know what the cause of the problem is. We know how to properly fix it. Why can't we have a proper fix?
This is a total blockstopper for my clients who run the printer.
Simply implement CORS headers for all your Web Service responses and we should be good.
Access-Control-Allow-Origin: *
They recently updated the beta version for windows of the dymo connect software. I was running into this issue and installing that version cleared it up for me. https://github.com/dymosoftware/Beta-Version
@lmason98 What if they could spend some time on actually maintaining these issue reports? Nah prolly takes a rocket engineer for that.
I gave up a long time ago and bought one of these Brother printers instead. Their JS SDK works great and the machine is a beast! https://amzn.to/3YBXum6
I too gave up and bought some used Zebra printers. I had it printing our stuff in ZPL in just a couple of hours, vs days of initial time investment getting Dymo Framework to run. So simple to use, both using the Zebra print service or printing directly to the printer's IP address!
@zsoden That's the right thing to do. I tried reaching out to DYMO management regarding this complete disaster they have for development. But they didn't want to hear from me. Totally their loss. I have discontinued all DYMO work. Some of my clients also got the Zebra instead. Happy to hear the move went well. I will spread the word.
I have exactly the same issue with the latest version of Dymo Connect and have found it frustrating that a fix does not appear to be forthcoming. Fortunately we still have one workstation with the old version of the software, but that's not a long term solution.
One possible alternative could be QZTray, which can be configured to print to a Dymo label printer from your web app, securely. I've been able to print what I need to from a browser to a Dymo using it, although the formatting is not quite right and as these are legally required 'dangerous goods' labels the formatting has to be exactly right.
This has been devastating for me as founder personally doing tech support. Thank you to anyone helping give us solutions.
This has been devastating for me as founder personally doing tech support. Thank you to anyone helping give us solutions.
The previous wording of my comment at the time was probably coloured by several wasted hours grappling with this issue, so I apologise for that: it was needlessly pejorative but I was not in a great frame of mind. I hope you do find a solution: the older version of the software functioned perfectly for many years printing direct from a browser (still is, on one PC).
@dartacus Don't feel like you need to apologize. We have all been there. This repository, the development team, and upper management has been a total disaster. Still is. Fact. I say speaking our minds is the best we can do to make ourselves heard. One day they might care.
Hi guys!
I'm also having trouble with the CORS issue for a while now. I'm trying to print labels from an ecommerce website so that my client can print the labels when they added new products.
Were now looking for other alternatives than Dymo. Any good suggestions? I prefer a printer that I can use with an javascript SDK
Thanks!
At this stage it's honestly better to create label pdf either client-side or server-side and present it for printing using normal printing dialog (for example using window.print()
of a child frame or window),
and wait for recently proposed Web Printing API to be implemented so you can engage any system printer directly.
I have already created a DYMO label parser (pre-Connect format), preview renderer and PDF export that works perfectly well with chrome.printing API, I just need to clear it with company before I can publish it on Github. Ideally creating vendor-indepentend label format would be best output so it can be printed on anything while maintaining element placement if different paper size is used, though even current form works on any printer.
For anybody else facing this issue, uninstalling and reinstalling Dymo Connect solved my issue - the CORS policy errors went away and I was able to debug again.
I was on windows 10. I saw about (KB5015807) on the software download center. I saw this one inside my update but not the fixed. So I installed all possible updates. Also I made sure I took the correct compatible software for the printer. https://www.dymo.com/support?cfid=dymo-compatibility-chart Than I rebooted and everything seems to be okay now.
Hi everyone, I'm working on project where my client want to print label direct from website it work fine 3 4 times then it is giving me error of CORS anyone have any idea how can I handle this error? TIA
I had a certain amount of success using QZTray to print to a dymo - it's fine as long as your formatting requirements aren't too complex. But my main solution is still just keeping an old copy of the dymo software for workstations which do labels.
A brief dig through the framework js file shows that the following endpoints are being hit:
/DYMO/DLS/Printing/StatusConnected /DYMO/DLS/Printing/GetPrinters /DYMO/DLS/Printing/OpenLabelFile /DYMO/DLS/Printing/PrintLabel /DYMO/DLS/Printing/PrintLabel2 /DYMO/DLS/Printing/RenderLabel /DYMO/DLS/Printing/LoadImageAsPngBase64 /DYMO/DLS/Printing/GetJobStatus /DYMO/DLS/Printing/Is550Printer /DYMO/DLS/Printing/GetConsumableInfoIn550Printer
Adding the vlue below to your Content-Security-Policy uner "content-src 'self'" should sort out the CORS issue: https://127.0.0.1:*/DYMO/DLS/Printing/StatusConnected https://127.0.0.1:*/DYMO/DLS/Printing/GetPrinters https://127.0.0.1:*/DYMO/DLS/Printing/OpenLabelFile https://127.0.0.1:*/DYMO/DLS/Printing/PrintLabel https://127.0.0.1:*/DYMO/DLS/Printing/PrintLabel2 https://127.0.0.1:*/DYMO/DLS/Printing/RenderLabel https://127.0.0.1:*/DYMO/DLS/Printing/LoadImageAsPngBase64 https://127.0.0.1:*/DYMO/DLS/Printing/GetJobStatus https://127.0.0.1:*/DYMO/DLS/Printing/Is550Printer https://127.0.0.1:*/DYMO/DLS/Printing/GetConsumableInfoIn550Printer
If I simply run the JavaScript demos untouched I get CORS errors from Chrome.
dymo.connect.framework.js:2 Access to XMLHttpRequest at 'https://127.0.0.1:41951/DYMO/DLS/Printing/RenderLabel' from origin 'https://XXXXX.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.