I have this weird requirement to access scanner, barcode reader, camera etc. from an asp.net application. Since these are local resources, i know its not possible to do that. I was wondering if there is some other solution to this problem.
I was thinking of creating an windows service that will run on local system and will open a port and listen to it and does the required job. I was wondering if there is a way to send some kind of message to the local port from an asp.net page using JS or some other library or activex.
If you have totally different solution, i am all ears.
We solved an analogous problem (ticket printer attached to serial port) by creating a tiny app (TCL/TK original, as it runs nicely on Win/Mac/Lin, but C#/.NET now since mono grew up), that
takes the user/password
creates the session with a web request.
opens the browser,
giving the session token in the URL as an anchor (http[s]://foo.bar/baz?x=y#sessiontoken)
This way it is never transmitted over the wire, but is available to the JS code in the client.
After the helper app has started the browser, it uses long polling and the session token (known to the browser and the helper app) to communicate with the webserver - as a client-sided app it can communicate with the peripherial quite naturally.
100's of 1000's of tickets printed this way ...
Edit:
Yes, I know this gets longer and longer, but I need (and was asked to) to elaborate.
If you want to avoid going the ActiveX/Silverlight/whatever route, which I strongly suggest, you need 4 players:
Webserver
Browser
Helper application ("Agent")
Device (Ticket printer, Barcode scanner, whatever)
Your basic problem is, that 1. needs to talk to 4., but can't. So you choose two parallell paths: Communication meant for the user is exchanged between server and browser, while communication meant for the device is exchanged between server and agent, the latter relaying it to the device (and ofcourse the other way round).
The agent is a quite simple application, that talks to the device via the OS facilities (how exactly this is done ofcourse depends on the device), and talks to the webserver via HTTP requests.
Depending, on which direction of information flow you need:
To facilitate information flow from the device to the server, simply
have activity on the device trigger a webrequest. (Input device, e.g. barcode scanner)
To facilitate information flow from the server to the devide, use long polling. (Output device, e.g. ticket printer)
For both directions do both (Server-triggered input device, e.g. camera)
Now the remaining problem is, how to correlate a human action in the browser with a device action - in short: How can the server send the ticket you chose in your browser to your ticket printer, not to whatever printer long-polls next.
To solve this, using the session ID is a natural fit - but it requires to have the browser and the agent both know the same session ID. For this to happen, you need to communicate it from one to the other. Since you can't communicate it from the browser to the agent (or this discussion would be moot), you need to communicate it the other way round - and the anchor in the URL is the vehicle to achieve this. You do the following:
User starts the agent (not the browser!) and enters his credentials
Agent calls sends a web request for a login to the server, and gets back a session token (please use some basic cryptography or go for HTTPS)
Agent then starts the browser (e.g. by executing cmd.exe /c start "http[s]://domain.tld/start.aspx?x=y#sessiontoken")
Since the session token is an anchor, it will not be sent over the wire, but will be available to the browser-sided code ... Bingo!
Now the two parallell paths are open: The browser for the human requests, knowing the session token, and the agent now going into the modes described above,
You can use ActiveX to do that or, maybe Silverlight (or Flash) which provide limited support for (at least in my experience Camera, Microphone and Scanner).
But, given a previously experience with something related to what you're trying to do I'll suggest you to better buy an SDK prebuilt.
Imaging:
http://www.viscomsoft.com/
Barcode:
http://www.tec-it.com/software/barcode-software/tbarcode/barcode-generator/Default.aspx
Related
In database some entity is getting updated by some backend process. We want to show this updated value to the user not real-time but as fast as possible on website.
Problems we are facing with these approaches.
Polling :- As we know that there are better techniques then polling like SSE, WebSockets.
SSE :- In SSE the connection open for long time(I search on internet and found that it uses long polling). Which might cause problem when user increases.
WebSockets :- As we need only one way communication(from server to client), SSE is better then this.
Our Solution
We check database on every request of user and update the value.(It is not very good as it will depend upon user next request)
Is it good approach or is there any better way to do this or Am I missing something about SSE(misunderstood something).
Is it fine to use SignalR instead of this all?(is there any long connection issue in it or not?)
Thanks.
It's just up to your requirements what you should use.
Options:
You clients need only the update information, in the case they make a request -> Go your way
If you need a solution with different client types like (Webclient, Winformclient, Androidclient,....) and you have for example different browser types which you should support. Not all browsers support all mechanisme... SignalR was designed to choose automatically the right transport mechanisme according to the mechanisme which a clients supports --> SignalR is an option. (Read more details here: https://www.asp.net/signalr) Has also options that your connection keeps alive.
There are also alternatives like https://pusher.com/ (For short this is only a queue where you can send messages, and also subscribe for messages) But these services are only free until for example some data volume.
You can use event based communication. When ever there is a change(event) in the backend/database, server should send a message to clients.
Your app should register to respective events and refresh the UI when ever there is an update.
We used Socket IO for this usecase, in our apps and it worked well.
Here is the website https://socket.io/
This is a theoretical question.
imagine an aspnet website. by clicking a button site sends mail.now:
I can send mail async with code
I can send mail using QueueBackgroundWorkItem
I can call a ONEWAY webservice located in same website
I can call a ONEWAY webservice located in ANOTHER website (or another subdomain)
none of above solutions wait for mail operation to be completed.so they are fine.
my question is why I should use service solution instead of other solutions. is there an advantage ?
4th solution adds additional tcpip traffic to use service its not efficient right ?
if so, using service under same web site (3rd solution) also generates additional traffic. is that correct ?
I need to understand why people using services under same website ? Is there any reason besides make something available to ajax calls ?
any information would be great. I really need to get opinions.
best
The most appropriate architecture will depend on several factors:
the volume of emails that needs to be sent
the need to reuse the email sending capability beyond the use case described
the simplicity of implementation, deployment, and maintenance of the code
Separating out the sending of emails in a service either in the same or another web application will make it available to other applications and from client side code. It also adds some complexity to the code calling the service as it will need to deal with the case when the service is not available and handle errors that may occur when placing the call.
Using a separate web application for the service is useful if the volume of emails sent is really large as it allows to offload the work to one or servers if needed. Given the use case given (user clicks on a button), this seems rather unlikely, unless the web site will have really large traffic. Creating a separate web application adds significant development, deployment and maintenance work, initially and over time.
Unless the volume of emails to be sent is really large (millions per day) or there is a need to reuse the email capability in other systems, creating the email sending function within the same web application (first two options listed in the question) is almost certainly the best way to go. It will result in the least amount of initial work, is easy to deploy, and (perhaps most importantly) will be the easiest to maintain.
An important concern to pay significant attention to when implementing an email sending function is the issue of robustness. Robustness can be achieved with any of the possible architectures and is somewhat of an different concern as the one emphasized by the question. However, it is important to consider the proper course of action needed if (1) the receiving SMTP refuses the take the message (e.g., mailbox full; non-existent account; rejection as spam) and (2) an NDR is generated after the message is sent (e.g., rejection as spam). Depending on the kind of email sent, it may be OK to ignore these errors or some corrective action may be needed (e.g., retry sending, alert the user at the origination of the emails, ...)
I am wondering if there is a good way of making automated system testing for a Chromecast receiver application?
If you open the application URL in a Chrome browser, the cast_receiver library cannot find the websocket connection on:
ws://localhost:8008/v2/ipc
Since this handles the communication between the app and the Chromecast hardware, I am thinking of something like a Node.js websocket server that can talk to the chromecast receiver app. Is there such a system, or do anyone know if there are plans of google releasing something for this kind of testing?
Also, would there be other problems related to the difference between the chromecast browser and chrome browser? As I understand, the chromecast browser is just a subset of chrome, which makes me think it should work.
No, there is no easy way to do this.
DISCLAIMER: I haven't tried any of what I'm about to suggest. It's also probably a terribly idea as Google could change the protocol any time and in any fashion they desire since it isn't a public thing.
BIG DISCLAIMER: You may be in violation of the ToS by doing this as Section 3.2 (Developer Policies) states that you "may not ... develop a standalone technology ... any functionality of any Google Cast Receiver". Possibly, you'd be making a standalone piece of technology that replicated the IPC functionality. But I don't know. I'm not a lawyer.
If you want to go and do this, I'd suggest making a copy of the Google Cast Receiver SDK (www.gstatic.com/cast/sdk/libs/receiver/2.0.0/cast_receiver.js as of April 28, 2015) and altering it so that it logs out the messages that are being sent and received.
Luckily, it appears that we have logging messages to help us find the relevant code.
The receiving method has the string "Received message". I would guess that "a.message" is what is being received.
The sending method has the string "IPC message sent". I would guess that "a" is what is being sent.
Once you've instrumented your copy of the code, you need to publish it somewhere that your receiver app can see it and then you need to edit your receiver app to point to your new and improved SDK. Please please please make sure that you do this on a non-published app for testing purposes only.
Once that is done, you need to find some way to get your messages out of the code and into something that you can access. You have a few options.
Fiddle around with the code more and figure out how to get the Chromecast to log out the data you want;
Store the information in an array and read it using the debugger;
Open your own socket (or websocket) and send that data to a server that you control.
From here, you can run your app, interact with it, and then have a complete record of the IPC messages that were sent and received. Armed with this, you can create your own Fake-IPC server that listens for specific messages and spits out the stuff that is in your log.
Say, for example, you are caching data within your ASP.NET web app that isn't often updated. You have another process running outside of the app which ocassionally updates this data, when you do this you would like the cached data to be cleared immediately so that the next request picks up the new data straight away.
The caching service is running in the context of your web app and not externally - what is a good method of calling into the web app to get it to update the cache?
You could of course, just hack a page or web service together called ClearTheCache that does it. This can then be called by your other process. Of course you don't want this process to be externally useable or visible on your web app, so perhaps you could then check that incoming requests to this page are calling localhost, if not throw a 404. Is this acceptable? Could this be spoofed at all (for instance if you used HttpApplication.Request.Url.Host)?
I can think of many different ways to go about this, mainly revolving around creating a page or web service and limiting requests to it somehow, but I'm not sure any are particularly elegant. Neither do I like the idea of the web app routinely polling out to another service to check if it needs to execute something, I'd really like a PUSH solution.
Note: The caching scenario is just an example, I could use out-of-process caching here if needed. The question is really concentrating on invoking code, for any given reason, within a web app externally but in a controlled context.
Don't worry about the limiting to localhost, you may want to push from a different server in future. Instead share a key (asymmetrical or symmetrical doesn't really matter) between the two, have the PUSH service encrypt a block of data (control data for example) and have the receiver decrypt. If the block decrypts correctly and the data is readable you can safely assume that only the service that was supposed to call you has and you can perform the required actions! Not the neatest solution, but allows you to scale beyond a single server.
EDIT
Having said that an asymmetrical key would be better, have the PUSH service hold the private part and the website the public part.
EDIT 2
Have the PUSH service put the date/time it generated the cipher text into the data block, then the client can be sure that a replay attack hasn't taken place by ensuring the date/time is within an acceptable time period (say a minute).
Consider an external caching mechanism like EL's caching block, which would be available to both the web and the service, or a file to cache data to.
HTH.
Since the Flash Player (or, more exactly, the URLLoader class) will not let you read HTTP response headers or cookies set by the server, and if you get hold of a session cookie through some workaround like reaching out to the browser and run JS, you can't send it to the server, because, among others, the Cookie header will be blocked.
Now I'm building a Flex client against an HTTP API for my server product. I control both sides, so I can get get around the above limitations, now I'm wondering how. I see the following options:
include the session token in the HTTP payload
include the token in the URL
build my own HTTP client (... with blackjack, and hookers ...) in AS, using the Socket class
I don't like (1), because I'm reimplementing functionality in my protocol that is already built into Struts, which I'm using to implement the server side. I then have to ensure that either both behave the same way, or turn off the usual way of session management and force other clients to use my protocol where they could just have the browser deal with it.
I don't like (2), because I understand that there are security concerns with this, although I'm not too sure which
I don't like (3), because it's 2010 and tons of HTTP clients have been written by smarter people than me.
So, are there other opportunities? Which of my "don't like"s do you reckon least severe? Are there ways to mitigate the problems I listed? For example, how insecure are session tokens in URLs really?
How about using the FlashVars parameter? It's designed explicitly to pass simple data into a Flash app, and it's trivial to embed the session token into the tag when the page is generated server-side. PHP-wise, it'd be something like
<embed href="movie.swf" flashvars="sessionID=<?= session_id(); ?>">blah blah blah</embed>
This way there's no session data in the movie's url that could leak via referers, and the data's already "there" so the app doesn't have to reach out and talk to the browser. And if someone's sniffing the source HTML page to get the data, they could have gotten the same information from the HTTP headers anyways.
There's more details here in the Adobe docs.
Some of your post may have eluded me, but do you know about Shared Objects:
"The SharedObject class is used to read and store limited amounts of data on a user's computer or on a server. Shared objects offer real-time data sharing between multiple client SWF files and objects that are persistent on the local computer or remote server. Local shared objects are similar to browser cookies and remote shared objects are similar to real-time data transfer devices.