I am a newbie dev trying to build a web application that can read and write to an RFID Card through the browser.
I am currently using an ACR122U Card Reader and have gotten it reading directly to my server in NodeJS with the nfc-pcsc node package.
Of course, I don't want to have my users have to run their own server and install a ton of libraries to read a card.
Ideally, they can just plug a card reader into their USB port and communicate from USB>Browser>Node Server and back again.
Can anyone recommend a good way to communicate with a USB RFID reader through the browser (and send to backend server?). Thanks
As far as I know, at the moment (Mar.2021) there is only experimental support for USB in browsers (WebUSB API). Please refer to https://developer.mozilla.org/en-US/docs/Web/API/USB
As this API is experimental, you may not want to rely on it for production. In this case, a component running on end users machine will be needed (e.g. a more or less simple service that responds via https at 'localhost'. This approach opens several usability/security concerns (such as supplying a trusted certificate for localhost, properly managing CORS headers etc).
You may want to refer to this question for additional suggestion: Architectures to access Smart Card from a generic browser? Or: How to bridge the gap from browser to PC/SC stack?
Related
I am doing some research on the WebUSB API for our company because we are going to start to manufacture devices in house.
Our current device manufacture comes with an application so the team can plug the device into a computer and diagnose it. Their application allows us to read outputs from the device, as well as pushing commands/configuration to the device over a wired connection.
Since this device is 100% ours, we are also responsible for building out the diagnostic tooling. We need some sort of interface that allows a user to read outputs and send commands/configuration to the device over a wired USB connection.
Is the webUSB the correct API? If not, what are some suggestions for accomplishing the requirement? Are we limited to building some sort of desktop or mobile application?
I would recommend resources below to read to help you understand if the WebUSB API fits your needs or not:
https://web.dev/devices-introduction/ helps you pick the appropriate API to communicate with a hardware device of your choice.
https://web.dev/build-for-webusb/ explains how to build a device to take full advantage of the WebUSB API.
From what you describe, WebUSB isn't strictly required but won't hurt either.
First and foremost, you will need to implement the USB interfaces reading data and sending configurations. It will be a custom protocol, and not one of the standard USB device classes such as HID, video or mass storage. The details of the protocol and if you use control, interrupt or bulk transfers is your choice.
I'm assuming you will connect the devices to Windows PCs, and you likely don't want to put money into writing device drivers. If so, the easiest approach is to add the required descriptors and control requests required for Microsoft OS 2.0 Descriptors. That way, the WinUSB driver will be installed automatically when the device is plugged in.
Using the WinUSB API, a Windows application will then be able to communicate with the USB device. No additional drivers are needed. (On macOS and Linux it's even easier as you don't need the Microsoft OS 2.0 Descriptors in the first place.)
On top of that you can implement the additional descriptors and control requests for WebUSB. It will provide the additional benefit that you can write a web application (instead of a native application) for communicating with the USB device. (Currently, you are restricted to the Chrome browser.) WebUSB devices should implement the WinUSB descriptors as the alternative (.INF files, manual installation process) is a pain.
The already mentioned web page https://web.dev/build-for-webusb/ is a complete example of how to implement it.
I would like to talk to a custom piece of hardware via my web application using WebUSB
The hardware is already able to communicate to a python script running on a laptop via USB
Now I have 2 questions and I hope you can help me :)
Does the hardware need to implement anything WebUSB specific? Or is the USB communication that is already implemented enough?
Is WebUSB ready for production? This application will be used by customers to talk to machines like excavators.
The whole application (talking to machines) already works via internet - we just need to implement the USB communication to handle the case that the user doesn't have a working internet connection.
best,
Kev
Does the hardware need to implement anything WebUSB specific? Or is the USB communication that is already implemented enough?
It is enough.
Is WebUSB ready for production? This application will be used by customers to talk to machines like excavators.
The Chrome team takes the decision to make a Web API available to developers very seriously and is committed to supporting these APIs for the long term. The draft status of the WebUSB API should not be taken as a reflection of the Chrome team commitment to this work. It is a necessary effect of how the web standardization process works.
The WebUSB API has been available for quite some time and is considered stable. While we have been making steady investments in the implementation of the API there are no changes to the developer-facing interface planned.
Since we need to have a UDP socket to discover the device, and since javascript seems not supporting UDP, is it possible to connect to Sony Camera Remote API with a javascript based mobile app (non native).
As said in the comments, you can use Cordova to do the SSDP discovery.
However, as far as I can see, the API is HTTP-based. So if you don't need discover (can write in the IP address and port manually), then this should be possible to do.
Did you ever get anywhere with this project? I'd be interested in getting some LiveView and controlling a camera using Javascript.
I want to develop a FirefoxOS privileged app that can send text messages to nearby devices.
Android app can use Bluetooth or Wifi P2P. But FirefoxOS privileged apps cannot use Bluetooth/Wifi API. These are only available for certified apps.
Privileged apps can use TCP socket API. Is this the only way?
Is there any way to get available IP addresses on LAN?
#Kazhik, unfortunately right now, that is the only way to go. And the explanation for that is that by using the socket API you can implement any protocol on top of TCP, such as IMAP, IRC, POP, HTTP, etc., or even build your own to sustain any specific needs you could have.
Since certified apps can only be included by the oem, access to Bluetooth or WiFi information API aren't a viable option now.
At today's date (September 18, 2015) the WebIDE supports installing certified apps in older Firefox OS versions like 1.3 and in physical devices.
I tried installing the Gaia test apps (these are certified) in one Alcatel OT FireC and everything worked perfectly fine ;)
DNS-SD (part of the Zeroconf specification) allows you to broadcast and receive "advertisements" from other devices on the local network. That requires UDP and TCP permissions, which means a "privileged" app, as you thought. That's not a problem, unless you need to distribute the app outside of the Firefox Marketplace.
There's an implementation of DNS-SD for JavaScript at https://github.com/justindarc/dns-sd.js
For compatibility with other messaging apps, you might want to implement XMPP:
http://www.xmpp.org/extensions/xep-0174.html
The Chromecast device is a "receiver device [that] runs a scaled-down Chrome browser with a receiver application". Can I download and install this receiver app on a chrome browser for example on my Windows notebook?
I have implemented a complete chromecast v2 receiver, called YouMap ChromeCast Receiver, available in Google play store and Amazon store, xda-developer thread here: http://forum.xda-developers.com/android-tv/chromecast/app-youmap-chromecast-receiver-android-t3161851
The current Chromecast protocol is a completely different one from the original DIAL based protocol. Right now, only YouTube still uses the old protocol, which chromecast maintains its backward compatibility.
The discovery is mDNS, exactly same as Apple TV bonjour protocol.
The most difficult part is device authentication, the sender and the receiver perform handshakes by exchanging keys and certificates in a way extremely difficult to crack. AppleTV does the same using FairPlay encryption.
The next difficult part is the mirroring protocol, which is also very complicated, need to deal with packet splits, packet retransmissions. Overall, chromecast mirroring protocol is well designed, better than miracast, better than AirPlay mirroring (I have also implemented both of them, so I know what I am talking about).
When I get chances, will write more here.
The chromecast device works using the DIAL protocol. It is completely possible to emulate this protocol using some simple code to listen on the multicast group for discovery and then handle the HTTP requests to launch applications. It is then the launched application that communicates with the casting device, I believe using the RAMP protocol.
Luckily for us the applications that the chromecast device uses are mostly web applications meaning our device emulator just needs to launch a web browser and point it to a specific url when it receives an application request.
For example the youtube app, after device discovery and establishing where the applications are located (part of DIAL). Will send a HTTP POST request containing a pairing key to /<apps url>/YouTube. All the emulating device needs to do now is open https://www.youtube.com/tv?<pairing key> in a browser window. From here, I believe, communication for controlling the youtube app is not sent through the casting device but through the open tabs on the casting device and the emulator.
This is my understanding of how the chromecast device works and specifically the youtube app from looking at https://github.com/dz0ny/leapcast which is a python emulator that has youtube and google music working.
Google is in progress of open sourcing some part of the chrome cast.
https://code.google.com/p/chromium/codesearch#chromium/src/chromecast/
https://code.google.com/p/chromium/issues/list?q=label:Chromecast
So theoretically you can build a similar device.