Webpage: accessing local file of the client / Alternatives to Silverlight / Java Applets

Question

We have the following requirement: the users of our website should be able to upload data from their handheld scanners to our web site.

The scanners are mapped to a local drive on the PC. It is pretty easy to write a .NET program and access the file from their device and send these files to a webservice.

Our users would like to have this directly from the webpage. They hit a button, and a component (of the website) reads the data from the device and sends it to the server.

I know that this should be possible with these technologies: * Java applet * Microsoft Silverlight * writing a rich client program which sends this to our web services (the users would like to get away from that)

Well both of them are not looking too attractive (isn't Silverlight dead anyways ?), so I would like to know if there are any other technologies which could be used to access a local file on the client from a web page ?

Answer 1

this is a recurrent question. I've tried some of the alternatives comented above and more or less they do the work.

For me, as a Java developer use a JavaFX applet seems the best option. What I did is not to create a visual applet which still being so heavy and hard to integrate with the web design. But instead I've created a 1px applet which exports javascript privileged functions. http://docs.oracle.com/javase/tutorial/deployment/applet/invokingAppletMethodsFromJavaScript.html

Anyway you must sign the applet using a valid CA and even with that you will still having issues with some users, annoying messages because java not updated, installed jre 32bits but using 64 bits browser, some antivirus produce applets malfunctions, etc...

Also you can use this framework to create a plugin for firefox, chrome and IE http://www.firebreath.org/display/documentation/FireBreath+Home The installation is almost transparent for the user, that does not need to have anything more than a browser installed. The cons is that you need to implement it in C++ so it is up to you do cross platform plugins, of course you need compile it one version for each operating system you want to support. Firebreath provide some commons API's supported in majors SO.

Other option useful in some (not all) cases: You can create a systray desktop app that can do the privileged work. That app can start a tiny web server binded in the localhost interface, the browser can use cross domain ajax calls to communicate with the systray app and send instructions and updates to the web app.

Anyway be carefully implementing this kind of solutions, that requiere a bit effort to offer a good experience to the user.

Answer 2

Since you seem to have a decent amount of control over your end-user's environment and the ability to have them install software on their desktop, I would consider registering a custom HTTP scheme that invokes your .NET executable to do the work. Registering a custom URI scheme is relatively straightforward with a couple of registry keys. If you register as an open/command like in that article's example, the browser will call your registered .EXE with the rest of the URL as your command-line parameter, and then your program can perform the work.

A benefit of this mechanism is that it works on the major browsers without having to write browser-specific code (plug-ins, etc.) From your perspective it's a little convoluted, because you will have the user invoke the external program, have it do the work, and then you need to detect on your page (ajax back to your server?) that the work got done, and allow the user to move on. But because you can pass a good bit of data to your program via the custom URI, the process could "feel" relatively seamless to your end user and not require much extra interaction, assuming they have the custom-scheme-handler installed.

A downside, though, is that (to my knowledge) detecting whether your URI scheme handler is installed on an end-user's system is not exactly simple in a cross-browser way from your web app. You may have to just let the invocation fail and pop up installation instructions if you detect on the server side that the helper app has not started and isn't working.

Even though this is not perfect, my experience is that signed java applets are getting increasingly harder for end-users to run. The browser vendors are blocking Java, or old versions of Java, or creating lots of security warnings, or Sun is changing the rules and requiring you to add things to your .JAR's manifest, or zealous firewalls just block signed .JARs altogether on the network layer because they might be malware, etc. You're going to find it is a hassle keeping up with that if you go the Java route.

Answer 3

One alternative on Chrome is develop a Native Messaging app or extension, that communicate with a native application on the user's computer by stdin and stdout.

Answer 4

JavaFX is some kind of Java Applet's next step (or steps), it could be helpful. Here is official JavaFX Overview.

Answer 5

Webapps are not allowed to access client's file system for security/privacy reasons. The user is the one who has to initiate a file transfer (upload).

HTML5 File API is also not usable because your webapp is allowed to play only inside its own sandbox.

Mozilla Firefox add-on might be able to do it, but your users must use Firefox. I don't know if Google Chrome extensions can do it.

The only browser-compatible way it the signed applet - those are used in eBanking webapps to access e.g. user's digital certificate from a CD/USB.