Troubleshooting
When users or clients can't connect to your Macromedia Flash Communication Server, what should you do? First, have them try out this link:
http://www.macromedia.com/support/flashcom/ts/documents/port_test.htm
The page will test connectivity between a small test SWF and the Macromedia server. It produces a report that looks like this:
Your test results were: WIN 6,0,79,0 RTMP DEFAULT Success RTMP 80 Success RTMP 443 Success RTMP 1935 Success HTTP Tunneling DEFAULT Success HTTP Tunneling 80 Success
Have your client copy the information and e-mail it to you. Use the results to determine what ports and protocols the client can use to connect to your server before you modify your application or reconfigure your server settings. If a client cannot connect at all during the Macromedia test, or if he can connect to Macromedia but cannot connect to your host, consider asking the user to contact his IT security group to see if he can alter the firewall so that he can connect.
In some cases, organizations decide to prohibit streaming access and configure their network firewalls, proxy servers, and packet shapers accordingly. In those cases, there isn't anything anyone can do. Sometimes organizations are willing to open access for specific cases. Be prepared to work with your client's IT security staff to resolve problems. Under rare circumstances, it is possible that a user's firewall will block access to your domain, but not to the Macromedia domain. The test on the Macromedia site is therefore not 100% foolproof—but it is another troubleshooting question you may want to pose to a customer's IT security staff.
Domain Restrictions
The default values in the Macromedia Flash Communication Server configuration
files let Macromedia Flash movies from any IP address attempt to connect
to the server. So, the default settings are not likely to lead to any
connection problems. However, you can restrict the IP or domain from which
a movie connects and the IP or domain from which the movie was served
by using tags in the server's XML configuration files. If you are having
connection problems and have changed domain or IP level access controls,
you should check them. In the following section, there is a brief explanation
of how some of the XML access tags such as <Allow>,
<Deny>, and <Order> work. For more
complete information refer to Managing
Flash Communication Server.
Client Address Restrictions
You can control access to applications on your communication server
based on the address of the client computer that plays a SWF. To control
access to applications by client address, use the <Allow>,
<Deny>, and <Order> tags in the
Adaptor.xml file. You can use host names, domain names, or partial domain
names as well as IP addresses and partial IP addresses. The tags in the
Adaptor.xml tag are supplied with the following default:
<Allow></Allow> <Deny></Deny> <Order>Deny,Allow</Order>
When the order is Deny,Allow, access is allowed by default
unless it is denied by the Deny tag. Since the Deny
tag is empty in the previous example, all users can access the server.
The role of the Allow tag is to provide limited access to
a subset of the addresses that have been denied. For example, to deny
access to every computer in the macromedia.com domain except one named
special.macromedia.com, you could use the following tags:
<Allow>special.macromedia.com</Allow> <Deny>macromedia.com</Deny> <Order>Deny,Allow</Order>
When the order is Allow,Deny, the server denies access
by default, as follows:
<Allow></Allow> <Deny></Deny> <Order>Allow,Deny</Order>
In this case, you grant access only to domains that you explicitly allow.
The Deny tag provides a way to further restrict what has
been allowed. For example to allow access only from Ryerson's domain but
not from a particular system at Ryerson:
<Allow>ryerson.ca</Allow> <Deny>netTester.ryerson.ca</Deny> <Order>Allow,Deny</Order>
You can specify more than one domain name or partial domain name, separating them with commas. To allow access from Ryerson and Macromedia but not to one machine at Ryerson, use the following syntax:
<Allow>ryerson.ca,macromedia.com</Allow> <Deny>netTester.ryerson.ca</Deny> <Order>Allow,Deny</Order>
The Server.xml file uses the same tags as the Adaptor.xml file to control access to the admin server rather than to applications on the communication server. For example, to deny admin server access to all IP addresses except those in a specific range, you might do something like this:
<Allow>141.117.27</Allow> <Deny></Deny> <Order>Allow,Deny</Order>
In this example, only computers whose IP address begins with 141.117.27 can connect. You can also control access to each virtual host's administrator within the Server.xml file. Clients that are refused access receive a NetConnection.Connect.Failed message with no other information.
Note: When you use domain names inside the <Allow> and <Deny> tags of the Server.xml or Adaptor.xml files, the communication server performs a reverse DNS lookup of the client's IP address to try to determine the DNS host name for the client. In many cases an Internet Service Provider, or another organization, may not include hostnames for each user's computer, and the lookup will fail. So you should not assume that by allowing a domain like ryerson.ca that all workstations at Ryerson will be able to connect. In Ryerson's case, the University has a class B range of addresses; so allowing all IPs starting with 141.117 will grant access to every workstation on campus. IP addresses are not always divided into classes, so this approach also has limitations.
SWF Origin Restrictions
Earlier I mentioned that the Macromedia Flash Player sandbox rules were
not in effect for RTMP (or for that matter for RTMPT or RTMPS) connections.
So, how do you protect Macromedia Flash Communication Server from accepting
connections from SWF files that don't originate from your domain? There
are actually two ways. One is to use the <Allow> tag
(and under some circumstances the DNSSuffix tag) in a Vhost.xml
file. The other is to use the client.referrer property in
the onConnect() method of each individual application. Using
the Vhost.xml file gives you virtual host-level access control; using
ActionScript to check the client.referrer property in individual SWFs
provides application-level control.
The default Vhost.xml file contains these tags:
<DNSSuffix></DNSSuffix> <Allow>all</Allow>
There are no <Deny> or <Order>
tags. Instead the keyword all indicates that any SWF can connect to an
application regardless of its origin. To limit communication server access
to SWFs that originate from specific domains, remove the all
value and replace it with a list of domains. For example, if you want
to permit only Macromedia Flash movies posted on hosts at Ryerson or Macromedia
to connect, use the following syntax:
<DNSSuffix></DNSSuffix> <Allow>macromedia.com,ryerson.ca</Allow>
Or, to permit movies served from one server at Macromedia, or any server at Ryerson connect, use the following syntax:
<DNSSuffix></DNSSuffix> <Allow>www.macromedia.com,ryerson.ca</Allow>
Using the <Allow> tag to get the server to check
the origin of a SWF is also called a referrer check. Macromedia Flash
Player provides the address the SWF file was downloaded from when it attempts
to connect to Macromedia Flash Communication Server. The server checks
this address against the <Allow> tag in the Vhost.xml
file.
There are cases when Macromedia Flash Player cannot send a referrer
address that can be checked against a domain. This can happen when the
player loads the SWF locally from the file system or when another communication
server is trying to connect. In these cases, Macromedia Flash Communication
Server looks at the IP address of the system trying to connect and tries
to get a domain name based on it. If the domain name system returns the
first part of a host name like www, but not a complete name like www.ryerson.ca,
then it rejects the connection unless it finds the rest of the host name
in the <DNSSuffix> tag. For example:
<DNSSuffix>ryerson.ca</DNSSuffix> <Allow>www.ryerson.ca,dcn.ryerson.ca</Allow>
When a client is refused access, the onStatus() handler
of the client's NetConnection object is passed an information object.
Its code property is NetConnection.Connect.Rejected, and the description
property contains additional information. For example:
[ Server.Reject ] : Rejecting connection from http://echo.ryerson.ca/refCheck/testClientwShowMessage.swf to rtmp:/testApp.
To perform a referrer check using server-side ActionScript you can
always do something like this in your main.asc file:
referrerList = {};
referrerList["http://echo.ryerson.ca/refTest/test.swf"] = true;
referrerList["http://141.117.27.180/refTest/test.swf"] = true;
application.onConnect = function(client){
if (! referrerList[client.referrer]){
return false; // Reject the connection!
}
return true; // OK, got this far - accept the connection.
}
The sample shown only allows a specific movie from one server to connect. By adding other full addresses to the referrerList, you can let other movies connect. You can also extract the host name from the URL and check it against a list:
referrerList = {};
referrerList["echo.ryerson.ca"] = true;
referrerList["141.117.27.180"] = true;
application.onConnect = function(client){
var hostName = client.referrer.split("/")[2];
if (! referrerList[hostName]){
return false; // Reject the connection!
}
return true; // OK, got this far - accept the connection.
}
Of course you could go further and break up the host name to look for a partial domain name. And server-side ActionScript even supports regular expressions if you want to use them.
Interinstance Communications
Some service providers disable the ability for Macromedia Flash Communication Server application instances to connect to each other using the NetConnection object. If you are unable to connect to another instance from within a Macromedia Flash Communication Server application, check with your service provider. Many will lift the restriction on request.
Submit feedback on our tutorials, articles, and sample applications.
