(Or how, I learned to stop worrying and tell people their solution is unsupported/ unsupportable)
I put this small "whitepaper" together after an issue came up where a customer's customer was reporting issues with scanning using an old DotTwain web-deployed as an ActiveX user control
I felt it was important to understand the history of scanning and why certain approaches are not only not supported but are actually not support-able (modern browsers deliberately breaking unsafe/insecure outdated technologies)
WEB DEPLOY
Before there was WingScan, before there was EZTwainX...
Customers wishing to build web based scanning applications needed to create an ActiveX user control which wrapped DotTwain (windows forms scanning component) then "web deploy" this ActiveX control in a full trust environment
This was supported with .NET framework 2.0
There were huge issues with making this work
This approach was never very good but it could work... but the full trust thing was a HUGE security risk
With the release of .NET framework 4.5, MS introduced a change. If you install the 4.5 framework on your system, it will disable IE's ability to use the Web-Deployed ActiveX embedded user controls, and you need to registry hack to re-enable it
FIX: Embedded .NET User Controls Suddenly Stop Working in IE
EZTWAINX
So… along came EZTwainX
Spike took EZTwain and crated a pure native ActiveX control, and for a period of time, we were selling it as a web scanning solution.
Any customers who were using Web-Deploy ActiveX were told to switch to it...
This solution was only usable in IE, and had some pretty severe limitations owing to having all images/scans reside in browser memory during the scan process.
WINGSCAN THE EARLY YEARS
Now, EZTwainX code was basically converted into the first generation of WingScan, and from its introduction in 10.0 until 10.5.2, WingScan was an ActiveX (native) plugin for IE, and an NPAPI plugin for Chrome and Firefox.
The plugins worked only in 32 bit browsers, and still suffered from some of the issues related to browser memory, as entire scan sessions were stored in memory of the browser until scan completion/posting the upload.
MODERN WINGSCAN
Then, in mid-2014, Google and Mozilla both announced they would be disabling NPAPI architecture for plugins (upon which our WingScan components pre 10.5.2 depend) and in January 2015, they started turning off NPAPI by default, and are now disabling it (but you can re-enable it on a site by site basis using Chrome's options) However, in September, even that option was removed.
In DotImage / WingScan 10.5.2, WingScan was re-architected to use the WebCaptureService
So, the ONLY supported web scanning from that time forward is using WingScan from 10.5.2 or later with the WebCaptureService handling the interaction with the local client TWAIN subsystem.
HOWTO: Migrate a WingScan based app to 10.5.2 (and newer - includes 10.6, 10.7, 11.0 and 11.1)
INFO: WingScan Whitepaper - Getting Started with Web Scanning
CHROME AND FIREFOX UPDATED TLS CERTS BREAK WINGSCAN
In or around May of 2017, Google Chrome stopped allowing certain types of self-signed certs for HTTPS connections. We had to issue an updated version of the web capture service which came out as version 10.7.0.11 in June 2017. Since then, we've made other fixes.. support's official position is that you should update to the latest 11.0 available. If you MUST use 10.7, then please use 10.7.0.13
FIX: HTTPS Errors Breaking Web Scanning: WebCaptureService Update Available
CONCLUSION
Atalasoft cannot support web based scanning with any component except the "modern" Web capture service-based WingScan implementation present in 10.5.2 or later, and due to HTTPS certificate issues, the lowest version support can recommend is 10.7.0.13. We strongly recommend using the latest build which is 11.0.0.7 (as of publication of this article in May 2018)
Original Article:
Q10461 - INFO: A Brief History of Web Based Scanning at Atalasoft