For information about security, see the Adobe Media Server Hardening Guide.

Restrict which domains can connect to a virtual host

If desired, you can restrict which domains are allowed to connect to a virtual host. By default, connections are allowed from all domains.

  1. Open the rootinstall/conf/ams.ini file.

  2. Set the VHOST.ALLOW parameter to a comma-delimited list of domains that are allowed to connect to the server. The default value is all.

    If a value is set, only the domains listed are accepted. For example, VHOST.ALLOW = example.com, example2.com allows connections from the example.com and example2.com domains. To allow localhost connections, specify localhost. For more information, see Vhost.xml file.

  3. Restart the server.

Verify SWF files

Flash Media Server 3.0, Flash Player 9 Update
3, AIR 1

[adoberuntime]Flash Media Server 3.0, Flash Player 9 Update 3, AIR 1[/adoberuntime]

Note:

To perform SWF verification for HTTP streaming, see SWF verification for Protected HTTP Dynamic Streaming.

You can configure the server to verify client SWF files before allowing them to connect to an application. Verifying SWF files prevents third parties from creating their own applications that attempt to stream your resources.

You can verify SWF files at the following server scopes:

  • Individual applications. Configure the application-specific Application.xml file.

  • All applications in a virtual host. Configure the Application.xml file in the Vhost folder.

  • Administrative applications that have access to all server levels. Configure the Server.xml file and an Application.xml file.

SWF verification is disabled by default. To verify SWF files, you must set <SWFVerification enable = "true"> in the Application.xml configuration file. When verification is enabled, the server verifies that the client SWF file requesting a connection to the server matches the verifying SWF file. The verifying SWF file is a copy of the client SWF file that you place on the server or in an external content repository.

By default, the server looks in rootinstall/applications/application_name/SWFs folder for the verifying SWF file. You can override this default in the SWFFolder tag of the Application.xml file, the Server.xml file, or in the File plug‑in. If you installed Apache with Adobe Media Server, you can add a path to the folder from which you serve SWF files. For example, on Windows, adding the path <SWFFolder>C:\Program Files\Adobe\Adobe Media Server 4\webroot</SWFFolder> prevents you from needing to maintain two copies of each SWF file.

Note:

If you’re deploying an Adobe AIR application, copy the SWF file you compiled into the AIR package to the server or external content repository.

When the client SWF file connects to the server, the server verifies it. If the SWF file is verified, it is allowed to connect to the application. If a client SWF file fails verification, the server disconnects the NetConnection object and logs an event to the access log. The server does not send a NetStream status message to the client.

For client applications that comprise multiple SWF files or SWF files that dynamically load other SWF files, the SWF file that contains the NetConnection object to connect to the server is the one that the server attempts to verify.

Note:

SWF files connecting to Adobe Media Administration Server cannot be verified.

Locating SWF files for verification

The server looks for verifying SWF files in the following locations, in order:

  1. The application-specific Application.xml file, if it exists. The Application.xml file defines the location of verifying SWF files in the SWFFolder tag. If SWFFolder contains a file path, the server looks for verifying SWF files in that file path. If SWFFolder is empty, the server looks in the default location: /applications/application_name/SWFs.

  2. The Vhost-level Application.xml file. This Application.xml file defines the location of verifying SWF files for all applications on the virtual host. The SWFFolder tag defines the location. If SWFFolder contains a file path, the server looks for verifying SWF files in that file path. If SWFFolder is empty, the server looks in the default location: /applications/application_name/SWFs.

  3. The server checks the SWFFolder tag in the Server.xml file. This tag specifies a location for global SWF files, which means SWF files that are common to all applications.

  4. If a File plug‑in is enabled for retrieval of SWF files, the server calls the File plug‑in. The server passes any values present in Application.xml or Server.xml to the plug‑in. The plug‑in developer overrides these values with paths to the external content repository.

Configure SWF verification for applications

  1. Locate the following section of the Application.xml file:

     <Application> 
         ... 
         <SWFVerification enabled="false"> 
             <SWFFolder></SWFFolder> 
             <MinGoodVersion></MinGoodVersion> 
            <DirLevelSWFScan>1</DirLevelSWFScan> 
            <MaxInitDelay>5</MaxInitDelay> 
            <FirstHashTimeout>5</FirstHashTimeout> 
            <FinalHashTimeout>60</FinalHashTimeout> 
             <UserAgentExceptions> 
                 <Exception to="" from=""/> 
             </UserAgentExceptions> 
             <Cache> 
                 <TTL></TTL> 
                 <UpdateInterval></UpdateInterval> 
             </Cache> 
         </SWFVerification> 
     </Application>
  2. Edit the following elements.

    Element

    Attribute

    Description

    SWFVerification

    enabled

    Set the enabled attribute to "true" or "false" to turn this feature on or off. The default value is "false".

    SWFFolder

    None.

    A single folder or a semicolon-delimited list of folders that contain copies of client SWF files. These SWF files are used to verify connecting SWF files. They are the verifying SWF files.

    The default value is the application's folder appended with /SWFs. For example, for an application called myApplication, if there isn’t a value set for this element, verifying SWF files should be placed in the applications/myApplication/SWFs folder.

    If you are using the File plug‑in to verify SWF files in an external content repository, leave this field blank.

    If you installed Apache with Adobe Media Server, enter the path to the folder from which you are serving SWF files. For example, if you’re serving SWF files from the webroot directory on Windows, enter the path C:\Program Files\Adobe\Adobe Media Server 4\webroot.

    Important: All SWF files in the specified folder are hashed and cached in memory when the server starts and every time the cache TTL expires. A large number of SWF files can result in start-up time delays and high memory usage.

    MinGoodVersion

    None.

    Specifies the minimum version of this feature to accept. The default value is 0, which allows this and all future versions. This is a reserved field that works with Flash Player; Adobe recommends keeping the default value.

    DirLevelSWFScan

    None.

    Specifies the number of levels of subfolders within a parent folder to scan for SWF files. The parent folder is specified in the SWFFolder element. Specifying a positive value scans that number of subfolder levels. Specifying zero scans the parent folder and no subfolders. Specifying a negative value scans all subfolder levels. The default value is 1, which means that the server scans only one subfolder level.

    MaxInitDelay

    None

    The maximum amount of time to process SWF files, in seconds. The default value is 5 seconds.

    FirstHashTimeout

    None

    The maximum amount of time that a client can use to provide its first verification to the server.

    FinalHashTimeout

    None

    The maximum amount of time that a client can use to provide its final verification to the server.

    UserAgentExceptions

    None.

    Container.

    Exception

    from

    to

    A user agent to except from verification. Use the from and to attributes to indicate the lowest and highest versions to except. This is a string comparison, with editing to make all numeric fields equal in length. For more information, see the comments in the Application.xml file and “Create verification exceptions” later in this topic.

    Cache

    None.

    Container.

    TTL

    None.

    The time to live for the SWF file, in minutes. The default value is 1440 minutes (24 hours). If a SWF file is removed from the server, the verification values stay in the cache for 24 hours; users can connect to the application until the cache expires.

    UpdateInterval

    None.

    The maximum time in minutes to wait for the server to scan the SWFs folders for updates when there is a miss in the cache. The default value is 5 minutes, which means a SWF file copied to the SWFs folder is picked up by the server within 5 minutes.

Create verification exceptions

  1. Add Exception elements to the UserAgentExceptions section of the Application.xml file.

    Certain applications—for example, Adobe® Flash® Media Live Encoder—do not support the form of SWF verification used by the server. You can add one or more exceptions to the SWF verification rules that allow specified user agents, such as Adobe Media Live Encoder, to bypass SWF verification, as in the following:

     <SWFVerification enabled="true"> 
         ... 
         <UserAgentExceptions> 
             <Exception to="FME/0.0" from="FME/2.5"/> 
         </UserAgentExceptions> 
     </SWFVerification>

Configure SWF verification globally

You can configure verification for a group of SWF files on the server that are common to all applications.

  1. In the Server.xml file Root/Server/SWFVerification/SWFFolder tag, specify folders that hold the verifying SWF files. You can also configure other values for these SWF files.

Note:

In addition to configuring the SWFFolder tag in the Server.xml file, enable verification in the Vhost-level or application-specific Application.xml file. See “Configure SWF Verification for Applications” in this topic.

Create folders for the verifying SWF files

  1. If the SWFFolder value is the default, create a folder called SWFs in the application’s folder on the server.

    For example, for an application called myMediaApp, create the folder applications/myMediaApp/SWFs. SWF files in the SWFs folder verify connections to any instance of the myMediaApp application.

  2. To verify SWF files for application instances, create instance folders in the SWFs directory, for example, applications/myMediaApp/SWFs/chat01, applications/myMediaApp/SWFs/chat02, and so on.

SWF files in the SWFs directory can verify all instances of the application; SWF files within an instance folder can verify only that instance.

Note:

Multiple SWF files may exist in either directory. A SWF file can be renamed and still used for verification as long as it’s a copy of the client SWF file.

Restrict access to the server with a cross-domain file

You can restrict access to an edge server or the Administration Server with a cross-domain XML file. The cross-domain XML file lets you specify a list of domains from which clients can access the edge server or Administration Server.

  1. Open rootinstall/conf/Server.xml and locate the CrossDomainPath element in the Server element (or the AdminServer element, for the Administration Server):

    <Server> 
        ... 
        <CrossDomainPath></CrossDomainPath>
  2. Specify the location of the cross-domain file in the CrossDomainPathElement, for example:

    <CrossDomainPath>C:/Security/config/files/ams/crossdomain.xml</CrossDomainPath>
  3. Validate the Server.xml file, save it, and restart the server.

Limit access to Adobe Media Administration Server

The Administration Console connects to Adobe Media Administration Server, which connects to Adobe Media Server. By default, the Administration Server in installed on port 1111. Adobe recommends that you block all external access to port 1111 so that access to the admin server is restricted only to clients that are within your firewall.

Additionally, you can restrict access to the admin server by using domain based restrictions.

By default, a client can connect to Adobe Media Administration Server from any domain or IP address, which can be a security risk. If desired, you can change this in the AdminServer section of the Server.xml file.

  1. Open rootinstall/conf/Server.xml and locate the following code:

     <AdminServer> 
         ... 
         <Allow>all</Allow> 
         ... 
     </AdminServer>
  2. Edit the Allow element to specify which connections to Adobe Media Administration Server the server responds to. This is specified as a comma-delimited list of host names, domain names, and full or partial IP addresses, as well as the keyword all. For example: <Allow>x.foo.com, foo.com, 10.60.1.133, 10.60</Allow>.

  3. Validate the XML, save the Server.xml file, and restart the server.

Set limits on unsuccessful login attempts

You can use the LogInLimits settings in the rootinstall/conf/Server.xml file to set the number of unsuccessful attempts a client is allowed when trying to log in to the admin server. With these settings, you define how many failed attempts are allowed before the client must wait to attempt to log in again. You also define the amount of time they must wait. In addition, you can lock the user out of the server entirely after a certain number of attempts.

To set the number of login attempts the client can have before waiting, use the MaxFailures sub-element. After that number of failures, the client must wait the number of seconds defined by the RecoveryTime sub-element. If the client tries unsuccessfully to log in a number of times equal to LockOutLimit, they are locked out of the server until the server is restarted.

In the following example, a user can try to log in 10 times. If they fail to log in successfully on the 10th attempt, they must wait 5 minutes (300 seconds) before attempting to log in again. If they fail 20 times total, they are barred from logging in until the server is restarted:<Security> <LoginLimits> <!-- Default value is 3 --> <MaxFailures>10</MaxFailures> <!-- Default value is 30 --> <RecoveryTime>300</RecoveryTime> <!-- Default value is 100--> <LockoutLimit>20</LockoutLimit> </LoginLimits> </Security>

For more information, see LogInLimits.

<Security> 
    <LoginLimits> 
        <!-- Default value is 3 --> 
        <MaxFailures>10</MaxFailures> 
        <!-- Default value is 30 --> 
        <RecoveryTime>300</RecoveryTime> 
        <!-- Default value is 100--> 
        <LockoutLimit>20</LockoutLimit> 
    </LoginLimits> 
</Security>

Configure SSL

Note:

Adobe Media Server uses OpenSSL libraries internally. To upgrade OpenSSL libraries, see TechNote 90293.

Secure Sockets Layer (SSL) is a protocol for enabling secure communications over TCP/IP. Adobe Media Server provides native support for both incoming and outgoing SSL connections. An incoming connection is a connection between Flash Player and the server. An outgoing connection is a connection between two servers.

RTMPS adheres to SSL standards for secure network connections and enables connections through a TCP socket on a secure port. Data passed over the secure connection is encrypted to avoid eavesdropping by unauthorized third parties. Because secure connections require extra processing power and may affect the server’s performance, use RTMPS only for applications that require a higher level of security or that handle sensitive or critical data.

By default, when Flash Player connects to Adobe Media Server, it scans the following ports in order: 1935, 443, 80, 80 (RTMP tunneling). To configure SSL, specify that a port is secure. To specify that a port is secure, place a minus (“-”) sign in front of the port number. The default secure port for RTMPS is 443. To configure the default secure port, enter -443 in the ADAPTOR.HOSTPORT parameter in the rootinstall/conf/ams.ini file, as follows:

ADAPTOR.HOSTPORT = :1935,-443

When Flash Player encounters an “rtmps://amsdomain/application” string, it communicates with Adobe Media Server over port 443. Adobe Media Server returns data to the client over port 443. Traffic with an “rtmp://” string uses port 1935.

To connect to Adobe Media Server over an SSL connection, clients must do the following:

  1. Set the NetConnection.proxyType property to "best" before connecting.

  2. Specify the RTMPS protocol in the call to the NetConnection.connect() method.

If SSL is configured, the following client code connects securely:

var nc:NetConnection = new NetConnection(); 
nc.proxyType = "best"; 
nc.connect("rtmps://amsexamples.adobe.com/vod/instance1");

If you configure any port other than 443 as secure, for example, -1935, the client must specify the port in the URI, for example, “rtmps://host:1935/app”.

Note:

All server editions support a version of RTMP called RTMPE, which is an 128-bit encrypted protocol. RTMPE is more lightweight than SSL and is enabled by default. For more information, see the NetConnection.connect() entry in the ActionScript® 3.0 Language Reference or in the ActionScript 2.0 Language Reference.

Certificates

You can get an SSL certificate from a certificate authority or create a certificate yourself. If a certificate is signed by an intermediate Certificate Authority (CA), it must include the intermediate certificate as part of the certificate that the server returns to the client. Your certificate file (if signed by an intermediate CA) should look something like the following:

 -----BEGIN CERTIFICATE----- 
 ... 
 -----END CERTIFICATE----- 
 -----BEGIN CERTIFICATE----- 
 ... 
 -----END CERTIFICATE-----

The first BEGIN CERTIFICATE/END CERTIFICATE pair is your certificate. The next BEGIN CERTIFICATE/END CERTIFICATE pair is the intermediate CA that signed your certificate. You can add additional sections as needed.

Secure incoming connections

Specify the location of the SSL certificate and the certificate’s private key, and configure the adaptor to listen on a secure port.

  1. Open the Adaptor.xml file for the adaptor you want to configure and locate the following code:

     <Adaptor> 
         ... 
         <SSL> 
             <SSLServerCtx> 
                 <SSLCertificateFile></SSLCertificateFile> 
                 <SSLCertificateKeyFile type="PEM"></SSLCertificateKeyFile> 
                 <SSLPassPhrase></SSLPassPhrase> 
                 <SSLCipherSuite>ALL:!ADH:!LOW:!EXP:!MD5:@STRENGTH</SSLCipherSuite> 
                 <SSLSessionTimeout>5</SSLSessionTimeout> 
             </SSLServerCtx> 
         </SSL> 
         ... 
     </Adaptor>
  2. Edit the following elements.

    Element

    Description

    SSLCertificateFile

    The location of the certificate file to send to the client. Specify an absolute path or a path relative to the adaptor folder.

    SSLCertificateKeyFile type="PEM"

    The location of the private key file for the certificate. Specify an absolute path or a path relative to the adaptor folder. The type attribute specifies the type of encoding used for the certificate key file. This can be either "PEM" or "ASN1". The default value is "PEM". The private key and the certificate can be combined into one file.

    If the key file is encrypted, the pass phrase must be specified in the SSLPassPhrase tag.

    SSLPassPhrase

    The pass phrase to use for decrypting the private key file. If the private key file is not encrypted, leave this tag empty.

    SSLCipherSuite

    The SSL ciphers: a colon-delimited list of components. A component can be a key exchange algorithm, authentication method, encryption method, digest type, or one of a selected number of aliases for common groupings. Do not change the default settings unless you are very familiar with SSL ciphers. The possible values are listed here: SSLCipherSuite.

    SessionTimeout

    The amount of time in minutes a session remains valid. Any value less than 1 is read as 1. The default value is 5. If a client reconnects to a session before SessionTimeout is reached, the cipher suite list isn’t sent during the SSL handshake.

  3. To configure a secure port for an adaptor, specify a minus sign before the port number in the ADAPTOR.HOSTPORT parameter in the rootinstall/conf/ams.ini file, as follows:

     ADAPTOR.HOSTPORT = :1935,-443

    This configuration tells the server to listen on ports 1935 and 443, and that 443 is a secure port that receives only RTMPS connections. An RTMPS connection to port 1935 fails: the client attempts to perform a SSL handshake that the server fails to complete. An RTMPS connection to port 443 succeeds: the client performs a SSL handshake that the server completes. An RTMP connection to port 443 also fails: the server tries to perform a SSL handshake that the client fails to complete.

  4. Restart the server.

  5. Check the rootinstall/logs/edge.00.log file to verify that no errors have been reported.

Configure incoming connections when multiple virtual hosts are assigned to one adaptor

You can configure the server to return a certificate based on which port a client connects to. This lets you assign multiple virtual hosts to one adaptor and return a different certificate for each virtual host.

Note:

Generally, if you’re hosting multiple customers, each virtual host has its own domain name. Each domain name must have its own certificate.

  1. Locate the following code in the Adaptor.xml file:

     <Adaptor> 
         ... 
         <Ho4stPortList> 
             <HostPort name="edge1" ctl_channel=":19350">${ADAPTOR.HOSTPORT}</HostPort> 
         </HostPortList> 
         ... 
     </Adaptor>
  2. Create new HostPort elements with unique name and ctl_channel attributes and unique port values for RTMP and SSL.

    For example, add the following HostPort tag in addition to the default HostPort tag:

     <HostPort name="edge2" ctl_channel=":19351">:1936,-444</HostPort>
  3. For each HostPort element, enter an Edge element under the SSL element with an identical name attribute. If you don’t specify an Edge element, the edge uses the default SSL configuration.

    This sample code demonstrates how to configure edge1 to return cert2.pem when a client connects to it on port 443. Since there is no Edge tag for edge2, edge2 will use the default configuration specified in the SSLServerCtx section that is directly under the SSL container tag. The edge2 server returns cert.pem when a client connects to it on port 444.

     <SSL> 
         <SSLServerCtx> 
             <SSLCertificateFile>cert.pem</SSLCertificateFile> 
             <SSLCertificateKeyFile>private.pem</SSLCertificateKeyFile> 
             <SSLPassPhrase></SSLPassPhrase> 
             <SSLCipherSuite>ALL:!ADH:!LOW:!EXP:!MD5:@STRENGTH</SSLCipherSuite> 
             <SSLSessionTimeout>5</SSLSessionTimeout> 
         </SSLServerCtx> 
         <Edge name="edge1"> 
             <SSLServerCtx> 
                 <SSLCertificateFile>cert2.pem</SSLCertificateFile> 
                 <SSLCertificateKeyFile>private2.pem</SSLCertificateKeyFile> 
                 <SSLPassPhrase></SSLPassPhrase> 
                 <SSLCipherSuite>ALL:!ADH:!LOW:!EXP:!MD5:@STRENGTH</SSLCipherSuite> 
                 <SSLSessionTimeout>5</SSLSessionTimeout> 
             </SSLServerCtx> 
         </Edge> 
     </SSL>
  4. Validate the XML and save the file.

  5. Restart the server.

Secure outgoing connections

  1. Open the Server.xml file and locate the following code:

     <Root> 
         <Server> 
             <SSL> 
                 <SSLEngine></SSLEngine> 
                 <SSLRandomSeed></SSLRandomSeed> 
                 <SSLClientCtx> 
                     <SSLVerifyCertificate>true</SSLVerifyCertificate> 
                     <SSLCACertificatePath></SSLCACertificatePath> 
                     <SSLCACertificateFile></SSLCACertificateFile> 
                     <SSLVerifyDepth>9</SSLVerifyDepth>     
                     <SSLCipherSuite>ALL:!ADH:!LOW:!EXP:!MD5:@STRENGTH</SSLCipherSuite> 
                 </SSLClientCtx> 
             </SSL> 
         </Server> 
     </Root>
  2. Edit the following elements.

    Element

    Description

    SSLRandomSeed

    The number of bytes of entropy to use for seeding the pseudo-random number generator (PRNG). You cannot specify anything less than 8 bytes, and the default value is 16. Entropy is a measure of randomness. The more entropy, the more random numbers the PRNG will contain.

    The server may take longer to start up if you specify a large number.

    SSLSessionCacheGC

    How often to flush expired sessions from the server-side session cache, in minutes.

    SSLVerifyCertificate

    A Boolean value specifying whether to verify the certificate returned by the server being connected to (true) or not (false). The default value is true. Disabling certificate verification can result in a security hazard. Do not disable verification unless you are certain you understand the ramifications.

    SSLCACertificatePath

    A folder containing certificates. Each file in the folder must contain only a single certificate, and the file name must be hash and the extension ".0", for example, e98140a6.0.

    On a Windows 32-bit operating system, if this tag is empty, the server looks for certificates in the rootinstall\certs directory. You can import the Windows certificate store to the certs directory by running AMSMaster -console -initialize from a command line.

    In Linux, you must specify the location of the certificates.

    SSLCACertificateFile

    Specifies the name of a file containing one or more certificates in PEM format.

    SSLVerifyDepth

    Specifies the maximum depth of an acceptable certificate. If a self-signed root certificate cannot be found within this depth, certificate verification fails. The default value is 9.

    SSLCipherSuite

    The SSL ciphers: a colon-delimited list of components. A component can be a key exchange algorithm, authentication method, encryption method, digest type, or one of a selected number of aliases for common groupings. Do not change the default settings unless you are very familiar with SSL ciphers. The possible values are listed here: SSLCipherSuite.

Configure adaptors to manage outgoing SSL connections independently

The SSL section in the Server.xml file configures all adaptors to use the same settings. However, you might want to use a different certificate for each virtual host. In this case, assign one virtual host to each adaptor and configure your adaptors individually to override the settings in the Server.xml file.

  1. Copy the SSL section in the Server.xml file to the Adaptor.xml files and enter the new values. You don’t need to copy the SSLRandomSeed tag, as this tag is a server-level setting that cannot be overridden in Adaptor.xml.

Configure virtual hosts to manage outgoing SSL connections independently

For example, you can disable certificate checking in one virtual host, use a certificate in a different folder for one virtual host, and implement a different set of ciphers in a third virtual host.

  1. Uncomment the SSL section under the Proxy tag in the appropriate Vhost.xml file:

     <VirtualHost> 
         ... 
         <Proxy> 
             <SSL> 
                 <SSLClientCtx> 
                     <SSLVerifyCertificate></SSLVerifyCertificate> 
                     <SSLCACertificatePath></SSLCACertificatePath> 
                     <SSLCACertifcateFile></SSLCACertificateFile> 
                     <SSLVerifyDepth></SSLVerifyDepth> 
                     <SSLCipherSuite></SSLCipherSuite> 
                 </SSLClientCtx> 
             </SSL> 
         </Proxy> 
     </VirtualHost>

    When the SSL tag is present, the entire SSL section is used to configure the virtual host. If an SSL tag is omitted from this section, the server uses the default settings.

  2. Restart the server.

Configure Adobe Media Server to work with a hardware SSL proxy

When you use a hardware SSL proxy, you don't need to configure Adobe Media Server for SSL. The hardware sits between Adobe Media Server and the Internet. Data sent between Adobe Media Server and the hardware is unencrypted. The hardware encrypts the data and forwards it to the Internet.

Configure the hardware to listen externally on port 443 to receive encrypted data sent over Internet from clients. Configure the hardware to forward data to Adobe Media Server on port 1935. Adobe Media Server listens on port 1935 by default. If you’ve changed the default port, configure the hardware to forward data on that port.

Configure RPCs (Remote Procedure Calls)

Adobe Media Server provides settings in the Application.xml file for configuring which RPC methods can be called. The default is to block all RPC calls.

You can enable RPCs by setting the <RPC> element’s enable attribute to true; for example:<RPC enable="true">

After enabling RPCs, you must then list individual methods that are allowed. Each type of class—Client, NetConnection, Stream, and SharedObject—has its own whitelist of methods that can be called. If a method or object is not explicitly listed in the whitelist, then it is considered blocked.

The settings for RPCs are in the <Security><RPC> element of the Application.xml file. This element contains the following sub-elements:

<RPC enable="true">
  • <Client> — All methods blocked by default.

  • <NetConnection> — Only the onStatus() method is allowed by default, if RPCs are enabled.

  • <SharedObject> — All methods blocked by default.

  • <Stream> — Only the onStatus() method is allowed by default, if RPCs are enabled.

Each of these sub-elements takes a <Method> sub-element. Each <Method> sub-element takes an <Allow> sub-element. The <Allow> sub-element is a comma-delimited list of allowed methods.

To add a method to a class’s whitelist:

  1. Enable RPCs by setting the <RPC> element’s enabled attribute to true; for example:<RPC enable="true">

  2. Add the method you want to allow to the class’s <Allow> element. The following example allows the getLocal() and setFps() methods to be called on the SharedObject class:<SharedObject> <Method> <Allow>getLocal,setFps</Allow> </Method> </SharedObject>

  3. Ensure that the defaults for the other classes meet your security standards. After enabling RPCs for all classes, you should review the default allowed methods.

The method names are case-sensitive and should be in one of the following formats:[objectPath.]method [objectPath.]object

If you allow an object but do not list its methods, then all methods of that object are allowed. For example, <Allow>a.b</Allow> matches methods a.b.c() and a.b.d().

Enable virtual directory mappings for server-side File objects

You can specify virtual directory mappings for server-side File objects in the Application.xml configuration file. However, the feature must be enabled at the server level in the Server.xml configuration file.

To enable virtual directories for server-side File objects, set the <VirtualDirectoryForFile> element’s enable attribute to true in the Server.xml file. In the Application.xml file, add a <VirtualDirectory> sub-element to the <ScriptingEngine><FileObject> element.

Only enable VirtualDirectoryForFile when you must provide virtual directories for server-side scripting; it is not required for adding virtual directories for streams. When virtual directories for File objects are enabled, anyone who has access to a server-side script can write files anywhere on the server disk. As a result, it is disabled by default. Activating it requires a configuration from the Server.xml file administrator.

If you map File objects in the Application.xml file and don’t have the feature enabled in the Server.xml file, the following message appears in the log:"Virtual directories for file objects is not supported due to the Server level security setting."

The following example enables virtual directory mappings for server side File objects in the Server.xml file:<Root> <Server> <Security> <VirtualDirectoryForFile enable="true"></VirtualDirectoryForFile> ... ... ... ...

The following example from the Application.xml file creates a new virtual directory mapping for server-side File objects:<Application> <ScriptEnging> <FileObject override="no"> <VirtualDirectory> /flashapps;C:\dev\Code\Flash\tincan\flashapps\ </VirtualDirectory> </FileObject> ... ... ...

"Virtual directories for file objects is not supported due to the Server level security setting."
<Root> 
    <Server> 
        <Security> 
            <VirtualDirectoryForFile enable="true"></VirtualDirectoryForFile> 
            ... 
        ... 
    ... 
...
<Application> 
    <ScriptEnging> 
        <FileObject override="no"> 
            <VirtualDirectory> 
            /flashapps;C:\dev\Code\Flash\tincan\flashapps\ 
            </VirtualDirectory> 
        </FileObject> 
        ... 
    ... 
...

This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License  Twitter™ and Facebook posts are not covered under the terms of Creative Commons.

Legal Notices   |   Online Privacy Policy