Telnet example and security

[Pleh]

Has anyone got the telnet example working from a webserver, it works localy, but due to security settings it wont work when accessed remotly.

I have played around with loads of security settings and have had no luck getting it working.

Is it even possible to use net sockets in AS3 when published to a web server?

If not, what use is a flash telnet client :p

Thanks

[dr_zeus]

It works if the server you're accessing has a crossdomain.xml that will allow SWFs from your domain to connect.

[Pleh]

So if im trying to conect to a router via telnet, i cant because the router is not also a web server. :(

what use is that?

[dr_zeus]

What use is it? Well, I'm guessing the person who wrote the telnet client in AS3 probably did it mainly because it's cool. For instance, I wrote some classes to connect to AOL Instant Messenger. In my case, I'll probably never be able to use them on a webserver because AOL most likely won't allow SWF crossdomain access to the AIM authentication servers, but it was a fun project that helped me learn to use sockets.

It's always important to consider Flash's security policies when you want network connectivity beyond the subdomain on which your SWF resides. In general, the location that you want to connect to in some way (whether it's via telnet, a custom HTTP client, or some other protocol), needs to be able to send the SWF a crossdomain xml file.

[Pleh]

Its a shame adobe dont just have a security popup that asks the user if they want to allow flash to access the remote site. Because the current security restrictions prevent us from using these extreemly cool apps :(

[dr_zeus]

The security restrictions aren't only for the user. They also exist because server operators don't necessarily want random people connecting to restricted resources. For instance, Flickr placed it's Flash-accessible stuff on api.flickr.com so that Flash cannot access certain things available on the main flickr.com domain.

Here's why! (http://www.petefreitag.com/item/348.cfm) That's scary.

[Pleh]

You can bypass the flash security by setting up a proxy on the domain that is hosting the flash file. so they havnt really prevented anything. just made it a pain in the ass.

and the link you suggested has nothing to do with this issue. Thats a general internet security hole that applys not only to flash.

I agree that security is a good thing, but its a shame that we cant just allow the user to choose if they wish to enable net sockets on their client when running from a remote server.

Its not really about protecting the server either because downloading the swf and running it localy has the same effect.

grr

[dr_zeus]

You can bypass the flash security by setting up a proxy on the domain that is hosting the flash file. so they havnt really prevented anything. just made it a pain in the ass.

Actually, they have prevented something. As you said, you can use a proxy on your server to connect to a service to "bypass" the restriction. When you do this, the service provider has still gained an advantage. Your connections are coming from a single source. It's a simple matter to ban your domain from connecting to the service if they don't like it. If the restriction weren't there, the service could potentially have thousands of connections from as many different sources that would be much more difficult to block.

and the link you suggested has nothing to do with this issue. Thats a general internet security hole that applys not only to flash.

I don't know why you think it has "nothing" to do with Flash. Yes, it's a general security hole that applies to other things as well, but Flash's security can help keep Flash from being a cause of that problem.

Its not really about protecting the server either because downloading the swf and running it localy has the same effect.

People generally don't do that.

[Pleh]

Actually, they have prevented something...
Good point, from a network admins perspective it is much easier. I agree, it is useful here, but i still feel that the cross domain security policy is holding flash back.

I don't know why you think it has "nothing" to do with Flash...
I feel it has little to do with flash, even in this instance, because there are numerous internet/server security holes that can be abused through any medium, including (but not limited to) flash. This particular example has nothing to do with the flash security issue, or even flash its self.

People generally don't do that.
Well at the moment, your right, they dont. but with all the new functionality in AS3, people will have to to run AS3 network applications properly.

[Tink]

and the link you suggested has nothing to do with this issue. Thats a general internet security hole that applys not only to flash.It's a general security hole that the Flash team have made efforts to address. This is a good thing.