Recently received a request to add communication to a device connected via serialport on the client's machine through my webpage.
I'd done some googling and found that node.js with node-serialport seems to be the javascript way of doing it. However, in my case, the device is actually connected to the client's machine, and not the server.
My question would be how do i implement node.js in this sense? Since the code is run at the client browser, is it possible for me to 'embed' node.js on my webpage?
Or is there any other alternative for doing this? Applet and ActiveX are out of the picture though.
Thanks
UPDATES:
Had managed to convince the client to have applet loaded from the web, so we'll be going through the applet route. Thanks all for your great info! =)
JavaScript in the browser only has access to the APIs provided by the browser: it lives in the browser sandbox where it (rightly) has no access to the client file system or other hardware.
This is different from node.js, which is a server implementation that has access to all sorts of other file system APIs.
To "break out" of the browser you must use some sort of browser extension.
You will have to create a plugin, an applet, or a client side application to get the data into the client's web browser before being sent off to your server.
You could make a small app that reads the serial port of the clients machine that creates a .js file, and then your web page includes that src of that "dynamically" created js file on the client's machine and presto your webpage gets access to the serial port in a roundabout way.
This is how GPSGate works: http://gpsgate.com/developer/gps_in_browser/
See also here: How to read from Serial port in a webpage
And a java applet based solution:
http://code.google.com/p/java-simple-serial-connector/
http://code.google.com/p/java-simple-serial-connector/wiki/jSSC_Terminal
Try app.js if you want to access node.js functions from browser.
This can only be done via Active X or a plugin like Java or Flash. Code in JavaScript is only as powerful as the APIs provided to it from the browser.
Want to sent an HTTP request to a server? JavaScript can do that (subject to the same-origin policy), because the browser has the XMLHttpRequest API. Want to query what processes are running on the operating system right now? JavaScript cannot do that, because no browser provides an API for querying the OS about what processes it is running.
No browser that I know of implements any kind of JavaScript API for performing serial port operations, so there is no way to do it without using a plugin.
However, this does not preclude the possibility of such an API existing someday: the getUserMedia function can grab data from a camera or microphone, and it could theoretically be expanded to get data from other devices as well.
Another option (other than ActiveX or Java applet with security permissions) might be Google Native Client and the Pepper API, though whether this would be sufficient to access a serial port, I do not know.
A Firefox extension can include a native XPCOM component that could access the serial port, and you might find there is already a way to access the serial port from browser chrome (which extensions are) because the security token and smartcard system supports serial readers. A Firefox extension could also be used to deliver the next solution, which requires placing a native component or application on the system.
Can you tell us what browser(s) and OS('s) are targetted here, and why ActiveX and Java are ruled out?
Others have suggested a native running proxy exposing the serial port through some protocol. You could use node for this, or python, or any other language that can create both a serial connection and a socket. To access the proxy from a browser application you would need special security permissions to be granted to the page, and then you can make your proxy an HTTP or WebSocket server. You can also serve javascript from the proxy which would grant the script HTTP and WebSocket access to it's origin server which is the proxy. Google Chrome extensions can access any destination and port with their socket client. Also, I believe a config can be set in Google Chrome to allow this for certain or every page, the same with allowing native client to be used by a webpage.
Without knowing more about your goal, I can't determine what the best solution would be.
Another option to read the serial port data is using sockjs and sockjs-client-node at the server side and sockjs-0.3.js at the client side.
Related
I'm looking for a trick to access an API on a server that I don't have access to using html/javascript. Usually browsers block this for safety reasons. Public APIs like google therefore support CORS headers that let the browser know that the source can be trusted.
I need the solution to be client side because the external API might not be accessible to the hosting server. I do not have access to the API providing server. Therefore options like JSONP and enabling CORS headers are not viable options.
I need a bit of creativity; options I'm considering:
building an application in c# or whatever that can connect to the server and then open a browser. I don't like this option much
Loading a java applet in the page that does the server connection. Also not really great (who uses java appletsanymore)
Thanks in advance,
You can create a simple server what acts as a proxy to provide you the required endpoints. It can be implemented in anything you can host on a server in the same domain like PHP, NodeJS, etc.. Since it won't run in the browser it will have no problem to access external servers.
If all your target devices support HTML5 you can use window.postMessage() too https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage
We are developing a web page that use https protocol (two way).
We need to access to the private certificates of the user, because we need sign documents by the user's certificate, so we developed a Java application that communicate with the web by a websoket.
This application will call with a protocol call since the web (same that when you open a pdf on Acrobat Reader from a browser).
So we have to be sure that our web is calling to the native application(only our web). We want develop a system to be sure of that. Our idea:
Send a public key, a signed token by the server's private certificate and a symmetric key (to encrypt websocket communications) to the native application.
Next, we will Check in the native application that the token it is OK with a web service to the server.
After, we will have to open the websocket between the native app and the web, and send the signed document by the native app by this way.
Then sent document to the server.
Is this implementation safe? We will be safe of a man in the middle?
Any suggestion about this solution will be wellcome, because I don't see any weakness but I am not an expert on security.
I know other solutions for this problem, like applets, JavaFX or native messages on Chrome, but I only want to know if these solution is safe.
Thanks to all in advance and sorry if my english isn't the best :P,
I see the following issues
Send a public key and a signed token by the server's private certificate to the native application.
You are calling a local app by protocol. For example mylocalapp://sign?securitytoken=.... You do not control which application is installed on local PC to respond to mylocalapp://. The browser shows an ugly warning because you are leaving the secure environment. An attacker could have replaced the default app, simulate the flow and get all signed documents.
2.Next, we will Check in the native application that the token it is OK with a web service to the server.
To verify identity of server and avoid a ManInTheMiddel attach you need also to set a trustore for your application with the server certificate
Your server needs also to verify identity of client. Are you planning to use TLS two ways also?
After, we will have to open the websocket between the native app and the web, and send the signed document by the native app by this way.
You do not need a websocket. Simply use a URL connection to download and upload the documents.
This solution was used by Spanish ministry of economy when chrome decided to cut the NPAPI support and signature applets began to fail. Now, they have rebuilt the system in this way
Install a local Java application on the user's PC. The application listens on a port as, for example 5678
In your page, javascript connects to the application in the form http://127.0.0.1:5678/sign and sends the data to sign.
The application is local and has no trouble using the operating system keystore, which includes drivers PKCS#11. Perform digital signature and sends the result to the server
The javascript of the page periodically query the result and retrieves it when ready
The security problem is basically the same, but install a server in localhost is harder than replace the local default app.
The solution is called #firma, I guess you probably know it. It is opensource, you can use it
I've read about WebSockets but they don't seem to be pure "sockets", because there is an application layer protocol over them. "ws:"
Is there any way of doing a pure socket connection from a web browser, to enliven webpages?
Here are my random stabs in the dark
Applets sockets provided by Java (need java installed)
Flash sockets provided by Flash (need flash installed)
But about HTML5, Why are they called WebSockets if they aren't Sockets?
Is the websocket protocol so simple to implement that it is "almost"-sockets?
I've read about WebSockets but they don't seem to be pure "sockets", because there is an application layer protocol over them.
[Is the] websocket protocol so simple to implement that [it is] "almost"-sockets?
Allowing regular socket connections directly from the browser is never going to happen because it opens up a huge risk. WebSockets is about as close to raw sockets from the browser as you are going to get. The initial WebSockets handshake is similar to an HTTP handshake (allowing web servers to proxy/bridge it) and adds CORS type security. In addition, WebSockets is a message based transport (rather than streaming as raw TCP) and this is done using a two byte header on each message frame.
Even flash is not able to quite make raw TCP connections. Flash sockets also add CORS security, but instead of an in-band handshake, flash socket connections make a connection to port 843 on the target server to request a security policy file.
Is there any way of doing a pure socket connection from a web browser, to enliven webpages?
Yes, you can use my websockify bridge/proxy which allows a WebSockets enabled browser to connect directly to a TCP socket via websockify.
But about HTML5, Why are they called WebSockets if they aren't Sockets?
WebSockets are a transport built on TCP sockets. After the handshake there is very minimal overhead (typically just a two byte header).
I can't improve on Kanaka's answers to your secondary questions, and I know this question is a year old. But for the main question, Is there any way of doing a pure socket connection from a web browser, to enliven webpages? There is a project called the Java / JavaScript Socket Bridge that might be what you (or anyone coming across this page from a Google search) are looking for. The advantage of this method over what others have mentioned is that it does not require either a client-side or a server-side service to be run. So, for instance, if you wanted to implement an IRC client purely in JavaScript but your web host does not allow you sufficient rights to proxy the connection, this Java applet would be the way to go. The only concern is making sure the client has Java installed and allowed.
You can just send data between a client and a server with WebSockets. Simply speaking, the only difference that WebSockets introduces is that the client:
adds some header bytes, like the type of data and the length
adds masks and encodes the data using them
The server also has to add header bytes, but does not need to encode the data.
If you implement the protocol correctly (server side, that is, since the browser already has an implementation), you can use it with ease to send text and binary data. (Although browser support is narrow, especially for the latter.)
The benefit of WebSocket is that it is HTTP based. You can use it also in environments there http proxies are used. Thus Websocket has a higher infrastructure compatibility as plain tcp.
Additionally http/WebSocket is providing you some features which you otherwise have to specify on your own:
Redirect
NAT keepalive
Multiplexing via URI
Framing
If you are asking for some data to be pushed from server it is widely termed as COMET or Reverse Ajax.
Web sockets is still not very popular as there are inherent firewall issues and minimal support yet from popular browsers.
You can take a look at http://www.ape-project.org/ as this is one of the most popular implementations (but native to unix/linux only for now. For windows they suggest using a virtual box or vmware based implementation)
You know, a web server. Right now my Socket.IO server loads from a BATCH file that is a JavaScript file. Can you use node and make the socket.io server load from a web browser. Like a web-server utility tool or something of the sort.
That's explicitly not possible due to the design of WebSockets. It starts as a special HTTP request that, after the handshaking, drops the HTTP protocol and strips it down into the WebSocket protocol -- a nearly bare protocol similar to (but slightly more managed than) raw TCP. Because a web browser specifically cannot handle HTTP requests, it could never initiate the socket as a server.
This was done specifically so it wouldn't be possible to write a drive-by botnet website to use scores of users' computers for DDOS attacks without their knowing, amongst other security concerns.
So it wouldn't surprise me if Flash supported that kind of behavior. ;) (I know Java can, but who enables Java applets?)
I'd say you Can. Not that I can think of a good use case.
You would need to put the startup code somewhere where the web server could run it and you would need to get the web server to return some information to the browser to allow it to then connect. You would also have to insert the socket.io code into the browser after the socket server had started.
So I Think that it would indeed be possible but rather complex for little gain. I suppose one possible use case would be to restart a socket server after failure. Actually I'd do that a slightly different way, probably by calling an external script from Node.
fortunatly the answer is no. if you mean by load / launched , NO. but you can create a script on a server that launch another server once a url is requested by a a client.
I have a browser based app that needs to communicate with another service running on the client machine via a socket connection from the browser using JavaScript.
I need to post and parse XML back and forth on the socket.
I am unable to go down the flash path as the cross domain security is a barrier, ie the service running on the socket is not able to be modified to support Flash's crossdomain security.
What are my options for a pure JS based solution?
You've got two major problems here:
It's difficult in javascript to access non HTTP resources,
It's difficult in javascript to access resources not loaded from the same server.
There are exceptions to both of these, but the conjunction of exceptions available might not exactly match with what you need. Here are some possibilities:
Some sort of proxy on your own server that connects back to the machine with the XML service on behalf of your web app.
If you can control the client machine somewhat you can run a server on it that can embed the XML in a JSONP formatted http response, you can access by adding simple script tags, and send messages the other way by using a script tag to request a url with your data encoded into it.
If when you say 'socket' you're referring to an HTTP connection, then there are a number of options, one is to add a Access-Control-Allow-Origin header to the HTTP, then you can do gets and posts using normal XMLHttpRequests in recent browsers.
Javascript will not allow you to create a socket connection to the client. It would violate the same origin policy. If you could somehow save an applet/swf to the local machine you could serve it up as file:/// and it could communicate to localhost (maybe! not tested).
Maybe creating a proxy to go in front of this unmodifiable socket server could open up some options for you. You could then use something like flash, or you could just not use sockets.
Your options for socket based interaction is limited to plugins that support such live functionality. The options generally break down as follows Flash, Java and Silverlight. All of which aside from Java, if I recall correctly, will have similar policy requirements.
If you control your own server, you could create a socket service to proxy the request to the final destination. Or, depending on the interaction, you can use standard Ajax-style requests and have the socket interaction on your server-side code. If you don't need a persistent connection, having the socket interaction via the server is your best bet.