I'm new in Adobe Air, I need (urgente!!!) to do a widget with Adobe Air that monitors the URLs where I navigate and when I enter to a specific site the widget appears in the front of my screen and display a message.
The problem is that I don't know how to listen the current URL of my browser using Adobe air (flash).
I was trying with HttpStatusEvent but I can figure aut how to retireve the URL from my browser.
Thanx!!
Carolina
See my answer to this question
This wouldn't be easy; it may be impossible. There are issues with timers and running AIR/Flash Player minimized. Things slow down so it is less of a drag on computer performance. AIR in the background may not respond the same way as an Active AIR application would.
In theory, you can write a Proxy in AIR using sockets and set the local browser to route all requests through the proxy. That probably isn't practical for wide use.
If you have control over the web page that you want to use to trigger your AIR app, you might be able to put a SWF on your web page and then use a LocalConnection to communicate between the browser SWF and the AIR app, forcing the AIR app to pop up.
AIR has no means to know if browser is running and what it does (barring NativeProcess helpers).
Flextras' answer made me think about proxies... Of course, proxy inside widget isn't practical. If widget is proxy, you can't have internet without it - that's silly. Instead, one can take an open source proxy, inside it check user agent header (to filter browser requests) and probably url (to exclude images, css and js requests). When you have request from browser and for html, you can make proxy open local socket connection to the same port your widget listens and notify it. But this can hardly be done urgently.
Related
I have a Flex based application which is using Flash Media Server (FMS) server (version 4.0) for live video streaming between two users (i.e. a one to one teleconferencing service). This streaming is one-to-one, as defined by business rules, so that no third person can join a teleconference. Either person can start the video stream via a browser-based Flex client and communication gets established once the second user joins. Validation for connecting the streams of the two users is implemented on the FMS server (as server side scripting defined in main.asc). I am facing three critical problems with our teleconferencing solution.
1.Often times, full communication can not be established between the two users. One user can not usually see or hear the other user. There is a client side 'refresh' button that when clicked, attempts to establish a connection via the server side script. This sometimes works. Before implementing our current server side script, I tried establishing a stream by using methods found here: http://forums.adobe.com/thread/905613
I think the method below may work as it would give me an array of subscribers to the stream.
getLiveStreamStats(appInst:String, stream:String) : Object
But the problem is that server returns the following:
<level>error</level>
<code>Admin.API.MethodNotAllowed</code>
<description>getlivestreams - Method not allowed!</description>
<timestamp>8/7/2012 10:05:38 AM</timestamp>
Question - Do I need to do anything different with the client or is it a server setting that needs modification?
You didn't specify if you were making the remote calls using HTTP or RMTP. If you're using RMTP you shouldn't have to do anything. If you're using HTTP you will need to modify the following files:
{Flash/Adobe Media Server Root}\conf\AMS.ini (or FMS.ini if you're on an older version)
{Flash/Adobe Media Server Root}\conf\Users.xml
In the first, you will need to set the USERS.HTTPCOMMAND_ALLOW option to true. In my version of the AMS.ini file it is at the very bottom of the configuration page.
In the Users.xml file, you will need to locate the block. In my version, this is also located towards the bottom of the page. The default install of Adobe Media Server 5 (in my case anyways) only allowed the "ping" method and all other methods were disallowed. You will either need to update that block to reflect a comma-delimited list of the methods you want to make accessible via HTTP (white listing) or allow all and deny none (I wouldn't recommend that).
Don't rely on a soft restart of the Adobe/Flash Media Server via the web based Administration Console. This did not work for me. I needed to restart the AMS service from within the Windows Services panel in order for the changes made in the configuration files to take effect.
I hope that this helps!
Rick
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
Hi guys how to detect all the browsers that are installed in a system.By using Flex
You cannot do that from Flex or, as far as I can tell, from any web application. A web app being able to go through the list of installed applications on client machine is bad from a privacy and security point of view.
Maximum you can do is to read the user agent string from the HTTP headers (which can be easily modified and hence need not be accurate) to check what's the current browser being used to access your application. Even this, you can't do from Flex, you'll have to do it using some server script and send the information to the Flex app.
#Amargosh, while you do have to go through the server page to get client information, you can simply get browser information by executing Javascript from Flex:
var result:String = ExternalInterface.call("eval", "navigator.userAgent");
This will do the trick.
Can anyone tell me why the Range, header is restricted in the Flash player?
I want to be able to pause and resume downloads in my flex application, but I get a RTE when trying to set the Range header.
Error #2096: The HTTP request header Range cannot be set via ActionScript.
I imagine there isn't going to be a work around client side, but expect there is a way you can get a server to change the name for the range header to something else...
Would like to know Adobe's reason for this though, hopefully it's not just to sell more copies of FMS :p
I just discovered exactly the same issue with the Range header while attempting to add ranged GET requests to our REST layer in Flex. Range is on the "blacklist" and the Flash Player simply won't send it.
Flash/Flex headers ate my brain a year or so back (verveguy.blogspot.com) but this is the last straw.
The solution I am now going to finally embrace is to use the open source as3httpclientlib and just abandon the Flash HTTP stack. We've used it successfully for some minor parts of our app (specifically, for talking to the JIRA API) so it's time to beat it into submission for all HTTP traffic.
For your specific problem, you could certainly switch to a custom header, say X-Range. This assumes you have control of the server side code and that you also have a crossdomain.xml policy file that allows headers. (Blacklisted headers are the first set to be culled. After that, the Flash player checks the crossdomain.xml advertised by the server you're talking to see whether it allows specific (or all other) headers)
Hope this helps
Here are a couple of Adobe Tech Notes that explain their reasoning:
Arbitrary headers are not sent from Flash Player to a remote domain
ActionScript error when an HTTP send action contains certain headers (Flash Player)
is it possible to make a Flex-application to only run from my domain? So a user can't copy the .swf and start it locally.
In a lot of cases this won't work because of the security model associated with the crossdomain.xml.
http://www.adobe.com/devnet/articles/crossdomain_policy_file_spec.html
Say for example, I have a flex app that has a service call and login to my backend database (perhaps PHP and mysql). Unless I explicitly enable it in crossdomain.xml policy file the app will not be able to communicate with my server unless the swf file is directly loaded from my domain. If the app was local it would look to my server like localhost was trying to access my backend through the flex app. So by default this would not work unless an explicit rule was put in place in the crossdomain.xml to allow access from localhost. Likewise someone cannot simply put the swf on a different server and try to access from my server unless I add that remote server to the crossdomain.xml policy.
So back to your question. Obviously, this crossdomain.xml stuff doesn't really apply if your flex app is really simple and does not try to make service calls to a server. For example, if you have simple game that just loads and plays without additional server calls inside the flex game.
If you wanted to protect your app you could have a basic "phone home" process during the startup sequence that makes a very simple server call to your website. It doesn't have to be anything super complicated, just require a round trip service call in the start up of your app. Perhaps check for a simple key or string stored in a variable on the PHP side, and don't let the flex app run unless that key is valid. You could hardcode the expected key inside the actionscript. Or perhaps have a basic logger that tracks how many times the app is launched and store the count in a database or something. The main thing is do not let the app completely launch until this request to the server has returned a valid result.
If you have this in place then the crossdomain.xml policies will kick in and if someone downloads your swf it shouldn't work because it will try to make a call from localhost to your server. Or if they steal your app and host it on their site it shouldn't work either.
The simplest solution il probably to check the value of
Application.application.loaderInfo.url
on application startup (for example in the applicationComplete event) and match it with your web site domain.
Do check out flash.System.Capabilities.playerType on LiveDocs as well.