How to detect all the browsers that are installed in a system? - apache-flex

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.

Related

Do I need to do anything different with the client or is it a server setting that needs modification?

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

URL detection adobe air desktop widget

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.

Who is calling my WebService?

I have a web service that is on an internal server. It can be called from any website on our network.
More and more developers are starting to use it. Current probably 20+ pages use this service, and the number is growing fast. I can see a year from now, someone asking what pages are using this service and what methods.
I would like to log the url of the pages that use my web service as the request come in.
It would also be nice to know the method they are calling.I need to do something in such a way, that it does not affect the client web sites.My first thought was that I could write some code in the global.asax.
I have added some code to the Application_BeginRequest to log the request object details, but there does not appear to be anything about the requesting url.
What am I missing? Should I be looking at a different object?
Thanks.
Without disrupting existing users this is going to be difficult. The httpContect.Current.RequestUrl will just return the URL used to call your web service, not which web page called it.
The closest you can do without disrupting existing apps and forcing developers to change them is to grab the HttpContext.Current.Request.UserHostAddress, so you can at least get the IP of the machine calling your service.
Beyond this, what you might want to consider is adding a parameter to your functions for "CallingApp" and then log that in your code. That's pretty much what we did once re realized that we needed to know which apps are calling our service. We actually have an application monitoring service that uses a GUID for every new app we develop, and we pass that GUID to any web service. It[s extra work but to us it was critical because it allows us to know which apps will be affected when we need to perform updates or take the app server down for maintenance.
Edit - added
As a side note, at the point we realized we needed to track this, we had already been using web services for about a year. When faced with the same problem, we created a new set of web services, and included the extra field for the calling app in all of the new services, and then slowly went back and changed the older programs to point to the new services.
IN retrospect, we wish we had known we would need to do this up front because it created a lot of extra work. I'm guessing you'll be facing something similar if you really want to know exactly who is calling your services.
The only thing you can probably retrieve from the consumer is the IP address without changing your interface.
If you can change this you could do this e.g. by adding authentication and logging who is calling what, or by having some simple "token" principle.
However both methods require you to change the interface and therefore break backwards compatibility - which you should never do.
By always ensuring both back and forward compatibility you should not need to know exactly who is calling your service, but only that it is actually used.
#David Stratton
Thanks for your help. I think your suggestions were great. I accually did something very different, after your answer gave me some new ideas.
I should have mentioned that I was generating the web proxy that most of my users were using to make calls against my web service. My client in general do NOT use the proxy that Visual Studio creates.
Here is what did:
I generated my web proxy client again, and added calls to log the httpcontext of the client before every call. Because the proxy is running on the client, he had access to everything I needed. That allowed me to record everything about the client and the specific call they were making. I realize this would not work for most cases. But all of my clients are internal web sites.
It also had the advantage in that the clients did not have to modify their code at all. I just gave them all a new DLL. Problem solved. I get all the tracking data I want, and they did not have to modify their code.
I was stuck trying to solve the problem from the web service's point of view.
I realize that there is still a whole in this implementation, because someone does not have to use my client proxy to call my service. I guess I could force that at some point in the future. For now, they could let Visual Studio genereate a web proxy for my service. However, if they do that I guess I don't care. That is not the recommened way to call my service. I think the only one doing that is an ASP.NET 1.1 web site. When they upgrade, they will probably switch to my generated proxy.
Without implementing some sort of authentication, there isn't a guraenteeted way of knowing exactly who is calling your service - web metrics are the only way you can gauge what volume of traffic is hitting your service.
I'm sure you already know this but the whole point of a web service isn't to know or care who is calling it.
I have successfully used ...
Dim strReferrer As String = HttpContext.Current.Request.UrlReferrer.AbsoluteUri
to get the calling page that called my WEB API 2 Web Service.

How to restrict a Flex application to only run from my website?

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.

How should I create cookie through flex/coldfusion that is readable by another template?

Inside a flex app, I have a user login. The login calls a ColdFusion function as a remote object which authenticates the user and, if applicable, returns their id and access level.
This works fine, but now I'm at the point where I want to also create a cookie for another ColdFusion template (called from fileReference.upload()) to be able to access later.
I have tried several different methods for creating the cookie -- cfcookie, creating a cookie with JavaScript inside the ColdFusion function, and creating the cookie with JavaScript with an external interface once the coldfusion function returns to the flex result handler. All of these have been tried with a plethora of options regarding expiration, path, and domain tags.
Any of these seems to work for cookie creation. Cookies show up in listings for my domain in Chrome as well as in a Firefox add-on 'View Cookies 1.9.2' that I've installed just for this purpose. Yet, still, none of these cookies seem to be readable by my upload.cfm when it is called later.
The upload.cfm, once called by a file upload request, sends the user id along with the file. From here, it should be a simple comparison between the id sent with the file and the id from the cookie. So far, the upload.cfm template has been unable to find the cookie (with any of the creation methods) looking at the obvious #cookie.name# or even #name#.
I'd appreciate any insight into why this is occurring, or perhaps an alternative method to the security I'm attempting to implement.
Thanks for reading,
-cs
Have you done most/all of your testing in a browser other than Internet Explorer?
Unfortunately, there is a bug in the Flash player [login required], which can be summarized as:
(In browsers other than Internet Explorer) The flash player uses a different network stack than the browser, and therefore...
Requests made by the flash player have a different server-side session than, for example, the request for the page that embeds the flash player.
This causes a situation whereby session variables set by the page are not (easily, by default) available to remote requests made by the flash player on the page.
CFID and CFTOKEN are set as cookies as well as stored in the session.urlToken variable. (JSessionId is included as well, if you're using Java session management).
I'm not positive, but I think this may be the root of your problem.
I believe that if you pass the CFID and CFTOKEN (and JSessionId) values to your Flex application as FlashVars, and then include them in the remote requests to the server, that the cookies you're setting will be available to later remote requests by flash (i.e. your upload).

Resources