cancel
Showing results for 
Search instead for 
Did you mean: 

Pulse Secure vADC

Sort by:
If you're running Apache HTTPD, you might have seen the recent advisory (and update) which can cause "significant CPU and memory usage" by abusing the HTTP/1.1 Range header.   If you're using Stingray Application Firewall simply update your baseline rules and you will be immediately protected. Otherwise, you can use TrafficScript to block this attack:   # Updated: Remove (if present) an old name that Apache accepts, MSIE 3 vintage http.removeHeader( "Request-Range" ); $r = http.getHeader( "Range" ); if( $r && string.count( $r, "," ) >= 5 ) { # Too many ranges, refuse the request http.sendResponse( "403 Forbidden", "text/plain", "Forbidden\n", "" ); }   This simply returns a 403 Forbidden response for any request asking for more than 5 ranges (at least 5 commas in the Range header). This is in line with the advisory's suggested mitigation: we don't block multiple ranges completely because they have legitimate uses, such as PDF readers that request parts of the document as you scroll through it, and the attack requires many more ranges to be effective.
View full article
Riverbed SteelApp™ Traffic Manager from Riverbed Technology is a high performance software-based application delivery controller (ADC), designed to deliver faster and more reliable access to Microsoft Azure applications as well as private applications. As a software-based ADC, it provides unprecedented scale and flexibility to deliver advanced application services.
View full article
The article Managing consistent caches across a Stingray Cluster describes in detail how to configure a pair of Stingray devices to operate together as a fully fault-tolerant cache.   The beauty of the configuration was that it minimized the load on the origin servers - content would only be requested from the origin servers when it had expired on both peers, and a maximum of one request per 15 seconds (configurable) per item of content would be sent to the origin servers:     The solution uses two Stingray Traffic Managers, and all incoming traffic is distributed to one single front-end traffic manager.   How could we extend this solution to support more than two traffic managers (for very high-availability requirements) with multiple active traffic managers?   Overview   The basic architecture of the solution is as follows:   We begin with a cluster of 3 Stingray Traffic Managers, named stm-1, stm-2 and stm-3, with a multi-hosted IP address distributing traffic across the three traffic managers Incoming traffic is looped through all three traffic managers before being forwarded to the origin servers; the return traffic can then be cached by each traffic manager   If any of the traffic managers have a cached version of the response, they respond directly   Configuration   Starting from a working cluster.  In this example, the names 'stm-1', 'stm-2' and 'stm-3' resolve to the permanent IP addresses of each traffic manager; replace these with the hostnames of the machines in your cluster.  The origin servers are webserver1, webserver2 and webserver3.   Step 1: Create the basic pool and virtual server   Create a pool named 'website0', containing the addresses of the origin servers. Create a virtual server that uses the 'discard' pool as its default pool.  Add a request rule to select 'website0':   pool.use( "website0" );   ... and verify that you can browse your website through this virtual server.   Step 2: Create the additional pools   You will need to create N * (N-1) additional pools if you have N traffic managers in your cluster.   Pools website10, website20 and website30 contain the origin servers and either node stm-1:80, stm-2:80 or stm-3:80.  Edit each pool and enable priority lists so that the stm node is used in favor to the origin servers:   Configuration for Pools website10 (left), website20 (middle) and website30 (right)   Pools website230, website310 and website120 contain the origin servers and two of nodes stm-1:80, stm-2:80 or stm-3:80.  Edit each pool and enable priority lists so that the stm nodes are each used in favor to the origin servers.   For example, pool website310 will contain nodes stm-3:80 and stm-1:80, and have the following priority list configuration:     Step 3: Add the TrafficScript rule to route traffic through the three Stingrays   Enable trafficscript!variable_pool_use (Global Settings > Other Settings), then add the following TrafficScript request rule:   # Consistent cache with multiple active traffic managers $tm = [ 'stm-1' => [ 'id' => '1', 'chain' => '123' ], 'stm-2' => [ 'id' => '2', 'chain' => '231' ], 'stm-3' => [ 'id' => '3', 'chain' => '312' ] ]; $me = sys.hostname(); $id = $tm[$me]['id']; $chain = http.getHeader( 'X-Chain' ); if( !$chain ) $chain = $tm[$me]['chain']; log.info( "Request " . http.getPath() . ": ".$me.", id ".$id.": chain: ".$chain ); do { $i = string.left( $chain, 1 ); $chain = string.skip( $chain, 1 ); } while( $chain && $i != $id ); log.info( "Request " . http.getPath() . ": New chain is ".$chain.", selecting pool 'website".$chain."0'"); http.setHeader( 'X-Chain', $chain ); pool.use( 'website'.$chain.'0' );   Leave the debugging 'log.info' statements in for the moment; you should comment them out when you deploy in production.   How does the rule work?   When traffic is received by a Traffic Manager (for example, the traffic manager with hostname stm-2), the rule selects the chain of traffic managers to process that request - traffic managers 2, 3 and 1.   It updates the chain by removing '2' from the start, and then selects pool 'website310'.   This pool selects stm-3 in preference, then stm-1 (if stm-3 has failed), and finally the origin servers if both devices have failed.   stm-3 will process the request, check the chain (which is now '31'), remove itself from the start of the chain and select pool 'website10'.   stm-1 will then select the origin servers.   This way, a route for the traffic is threaded through all of the working traffic managers in the cluster.   Testing the rule   You should test the configuration with a single request.  It can be very difficult to unravel multiple requests at the same time with this configuration.   Note that each traffic manager in the cluster will log its activity, but the merging of these logs is done at a per-second accuracy, so they will likely be misordered.  You could add a 'connection.sleep( 2000 )' in the rule for the purposes of testing to avoid this problem.   Enable caching   Once you are satisfied that the configuration is forwarding each request through every traffic manager, and that failures are appropriately handled, then you can configure caching.  The details of the configuration are explained in the Managing consistent caches across a Stingray Cluster article:     Test the configuration using a simple, repeated GET for a cacheable object:   $ while sleep 1 ; do wget http://192.168.35.41/zeus/kh/logo.png ; done   Just as in the Consistent Caches article, you'll see that all Stingrays have the content in their cache, and it's refreshed from one of the origin servers once every 15 seconds:   Notes   This configuration used a Multi-Hosted IP address to distribute traffic across the cluster.  It works just as well with single hosted addresses, and this can make testing somewhat easier as you can control which traffic manager receives the initial request.   You could construct a similar configuration using Failpools rather than priority lists.  The disadvantage of using failpools is that Stingray would treat the failure of a Stingray node as a serious error (because an entire pool has failed), whereas with priority lists, the failure of a node is reported as a warning.  A warning is more appropriate because the configuration can easily accommodate the failure of one or two Stingray nodes.   Performance should not be unduly affected by the need to thread requests through multiple traffic managers.  All cacheable requests are served directly by the traffic manager that received the request.  The only requests that traverse multiple traffic managers are those that are not in the cache, either because the response is not cacheable or because it has expired according to the 'one check every 15 seconds' policy.
View full article
This article combines two Stingray technologies – Java Extensions and the Control API – and shows you how to query the status of Stingray with a simple, authenticated web request to generate an immediate status report.   Introduction   Stingray’s admin interface gives you plenty of useful information about the performance and health of Stingray, but sometimes you may want a lighter, quicker way of checking the status. Apache's ServerStatus page is a good model of a report that you can access from within a public website using a privileged URL.   This article presents a Java Extension that generates a similar report. The Java Extension is run when a particular URL is requested and appropriate authentication is given; the extension queries Stingray via the SOAP-based Control API and retrieves a range of status information and a list of the recently-processed connections.   Before you proceed   First, follow the instructions in the article Using Stingray's SOAP Control API with Java to create an appropriate Stingray-API.jar file. Upload this interface file to the Java Extensions catalog in the Stingray admin interface, and ensure that all of the the required dependencies are also installed in the Java catalog.   The Java Extension   The attached Java Extension source file (ServerStatus.java) is quite long; you can shortcut building it from source by using the attached ServerStatus.jar file and uploading it straight to the Java Extensions catalog in Stingray.   Compiling the extension   At compilation time, the extension will require the Stingray-API.jar and Apache Axis 1.4 jar files for type checking. For example, if you use the Eclipse IDE, you should add these files as 'External Jars' in the build path.  From the command line:   $ javac -cp Stingray-API.jar:zxtm-servlet.jar:servlet.jar:axis-1_4/lib/* ServerStatus.java   The extension compiles to several separate class files. You can upload each class file to the JAva catalog, or you can use the 'Export' command (in Eclipse) to create a Java jar file containing the compiled class files from the ServerStatus project. From the command line:   $ jar -cvf ServerStatus.jar ServerStatus*.class     Using the ServerStatus Java Extension   The ServerStatus java extension prompts for a username and password; provide the username and password for the 'admin' user in the Stingray Admin Interface.   Use the following RuleBuilder request rule to invoke the extension:     ... or the equivalent TrafficScript rule:   $path = http.getPath(); if( $path == "/serverstatus" ) java.run( "ServerStatus" );   Then, go to http://www.site.com/serverstatus to run the extension: Security   The extension first checks that the HTTP request that has invoked it contains a username and password. If the username and password is missing, the extension returns a '401 Authenticate' message to prompt the caller to provide them. The caller should provide the username and password for the 'admin' user in the Stingray Admin Interface.   The extension then attempts to connect to the local Stingray Control API interface using the supplied username/password pair. If the connection fails because the authentication details are invalid, the extension again prompts for a new username and password.   Use SSL!   When you provide the admin user and password, it’s very advisable to only do so over an SSL-enabled website. You can ensure that the user name and password is never requested by a non-SSL site by modifying the rule as follows:   $path = http.getPath(); if( $path == "/serverstatus" && ssl.isSSL() ) java.run( "ServerStatus" );   If necessary, configure a special SSL virtual server in Stingray to host the extension. The extension will return identical results no matter which virtual server it is invoked from.   Read more   Tech Tip: Reading Stingray's internal diagnosis report using Perl and SOAP Java Extensions - Overview Using Stingray's SOAP Control API with Java
View full article
As the content on websites grow, the structure of their URLs can change dramatically.  The addition of new applications and components can play havoc with the established URL space, and the development cost of supporting the old links that have been published in articles, referenced by search engines and bookmarked by users can be very high.   Stingray is in a great place to address this problem, and let your applications use the URL spaces most suited to them with little concern for backwards compatibility.  This article presents one technique you can employ to access this problem in a scalable and manageable manner.   A simple example   Let's start with a simple example; suppose you published content at the following URLs:   www.example.com/news.html www.example.com/about.html www.example.com/careers.html www.example.com/demos.html   As your company grew, offices were added, more products were developed and content began to be broken out by location.  The original URL structure was no longer sustainable, and a deeper layer of content was necessary:   www.example.com/corporate/news.html www.example.com/product/news.html www.example.com/product/demos.html www.example.com/about/cambridge.html www.example.com/about/honalulu.html www.example.com/careers/overview.html www.example.com/careers/honalulu/engineering.html www.example.com/careers/cambridge/research.html   The challenge is to serve out the best content to people who make requests to the old URLs.  You want a better solution than manually adding redirects to your webserver configuration file; ideally a solution that can be used by your web content team without the intervention from IT.   A solution   Ideally, we would like to issue an HTTP redirect to the most appropriate page. This is, of course, simple using TrafficScript.   1 http.redirect( "http://www.example.com/corporate/news.html" );   ... but you want to avoid having to build and maintain a rule that looks like this:   1 2 3 4 5 6 7 8 9 10 11 12 13 $url = http.getPath();   if ( $url == "/news.html" ){       http.redirect( "http://www.example.com/product/news.html" );   } else if ( $url == "/about.html" ) {       http.redirect( "http://www.example.com/about/cambridge.html" );   } else if ...   }   Wouldn't it be easier if you could maintain a file with a list of redirects, and Stingray could act on that?   /news.html http://www.example.com/product/news.html /about.html http://www.example.com/about/cambridge.html   etc...?   You can use the ResourceTable libraries from HowTo: Store tables of data in TrafficScript - part 1 to help you do exactly that:   1 2 3 4 5 6 7 import ResourceTableSmall as table;    $path = http.getPath();    $redirect = table.lookup( "redirects.txt" , $path );   if ( $redirect ) http.redirect( $redirect );   Managing the file of redirects   That leaves us with one problem - how best to manage the (albeit simple) file that contains the redirects?  The format is simple enough (space-separated key / value pairs, one per line) that anyone can edit it, but how do they get it into the Stingray configuration without using the complex and powerful Stingray Admin Interface?   There are a couple of simple approaches:   Use the Stingray Admin Interface, and give the user a permissions group that only gives access to the Extra Files catalog; Push the file in using one of Stingray's configuration APIs - Feature Brief: Stingray's RESTful Control API or Feature Brief: Stingray's SOAP Control API; Copy the file in using SSH, and then invoke ZEUSHOME/zxtm/bin/replicate-config to push the configuration across the cluster.   The REST approach is particularly attractive - you can use browser plugins like Chrome's REST Console to push configuration files into Stingray.   However, you may not want someone to use either approach directly because it would imply giving them a full administrative logon to the Stingray cluster.  In that case, you could consider a simple commandline tool that they can use to upload the updated configuration file, using the Collected Tech Tips: Using the RESTful Control API or  Collected Tech Tips: SOAP Control API examples APIs.
View full article
Introduction Riverbed Stingray Traffic Manager is the only pure software ADC (Application Delivery Controller) available in the market today. As such it is the only ADC which can move with your business across Physical, Virtual, and Cloud platforms, and give you the exact same features and performance in each. Today Riverbed provides Stingray in the form of Virtual Appliances for many of the popular Hypervisors (including VMWare, Xen, and Hyper-V). The Virtual Appliance can also be provided in the standard OVA (Open Virtualization Archive) format for importing into a number of other Virtual platforms. For systems such as IBM PureFlex, where the Virtual Appliances are more closely integrated with the underlying platform it can be beneficial to build a completely custom appliance using the software edition of Stingray. IBM provides a tool precisely for this purpose: The Image Construction and Composition Tool (ICCT). This document will take you through the process of building a customised Stingray appliance for deployment on PureFlex using the ICCT. A very similar process can be followed to deploy an image into IBMs Smart Cloud Enterprise. IBM Image Construction and Composition Tool ICCT is a tool which allows a user on a PureFlex or Smart Cloud Enterprise platform to create custom Virtual Appliances. A full description of the ICCT application is beyond the scope of this document. We will assume that the ICCT has already been configured to communicate directly with your PureFlex or SCE environment and we will concentrate solely on the configuration elements required to build a custom appliance. These include: Managing ISO Resources, Managing Software Bundles, and Managing Images. ISO Resources An ISO resource is simply an ISO containing a compatible Operation System image. The ISO can be used to deploy new images from scratch. In terms of Stingray, the only PureFlex/SCE supported Operating Systems are Red Hat Enterprise Linux, SuSE Enterprise Linux. Software Bundles Along with this document, you should have been provided a prebuilt Stingray Software Bundle (a RAS file). The RAS file contains a number of scripts which are used by PureFlex or SCE in building and deploying custom appliances. A software Bundle includes four main configuration items: the installation script, the configuration script, a reset script, and some firewall configuration. Images An image is essentially a Virtual Machine. An image appears in ICCT either when it is created by deployment from an ISO, when it is imported from a connected SCE or PureFlex system, or when an existing image is extended. Build Process The process of building a custom appliance will be explained in detail in the section “Creating a custom Stingray appliance” below. As a quick overview the process is as follows: Take an image of a BaseOS and extend it. Add the software bundle to the extended image and configure the installer parameters. Deploy the new image (installer script is executed). Log on to running virtual machine and check installation succeeded. Capture the image. Export/deploy the image into PureFlex Manager/Smart Cloud Entry as an appliance Deploy an instance from the appliance image (the configure script is executed). The Stingray Software Bundle (RAS) The software bundle provided has everything you need to build a custom Stingray appliance for use in PureFlex or (with a little tweaking) Smart Cloud Enterprise. The RAS file includes a number of scripts which we discuss in turn. Installation Script The installation script “install.sh” is executed when the image is deployed for the first time. Its purpose is to download the Stingray software and Kernel modules from a HTTP repository and install them in to the image. The installer takes two arguments: stmUrl The URI for the Stingray software installer. Default version 9.1 from support.riverbed.com modsUrl The URI for the Stingray Kernel Modules installer Default: Version 2.5 from splash.riverbed.com The stingray installation needs nothing more than a Base OS install, however you will need to ensure that you have the development tools and kernel headers available in order to install the kernel modules. Note: It is recommended that you check the installer output in /var/log/provision.log after the initial deployment to ensure that everything worked. This is also a good opportunity to apply the latest security patches and bug fixes to the underlying OS. Configure Script The configuration script “configure.sh” is executed each time an instance is deployed from the appliance image. The configure script has the task of configuring the Stingray software in the appliance according to the parameters provided in the deployment form. The configure script in the provided RAS takes the following arguments: password The password for the Stingray admin user. Set password to “RANDOM” to have one generated for you. Default: “” accept_license Set to “Accept” if you agree to Stingray licensing terms. The configure script will not continue if this has not been set. Default: “No” license_key Should be “none” or a HTTP URI from where a license can be downloaded. Default: “none” join_cluster Should be “No” or “Yes”. Default: “No” cluster_host Should be “none” or an IP address or hostname of a Stingray to cluster with. Default: “none” cluster_tips Should be “No” or “Yes”. Default: “No” cluster_location The id of the location to join if we are joining a MSM cluster. Default: 0 cluster_external_ip If we are joining a cluster on the other side of a NAT device, then this should be our external IP Address. Default: “none” Reset Script The reset script “reset.sh” is executed whenever the appliance needs to be cleaned up and returned to an unconfigured state. I don’t believe it is ever actually used, but a reset script is provided. It takes no arguments. Firewall Configuration The final piece of configuration in a software bundle is the firewall configuration. This allows you to specify which ports should be open on the firewall. The Stingray bundle currently opens port 9090 and 9080 for cluster communications and administration. You will want to add all of the service ports you expect to use on your Stingray appliance. For example HTTP (80), HTTPS (443), etc. Miscellaneous All scripts write their output to /var/log/provision.log so you can always check that to see if there were any problems with the install, configure or reset steps. The software bundle includes AutoScaling drivers for Smart Cloud Enterprise, and also Smart Cloud Entry provisioning APIs. If you do not join a cluster during the deployment of an instance then the configure script will drop them into the extra files catalogue. However if you do join a cluster, then they will be copied into the root users home directory “/root”. Creating a custom Stingray Appliance Step 1: Upload your ISO The first step is to provide ICCT with an ISO containing the Operating System you wish to use. At the time of writing PureFlex and SmartCloud support RedHat Enterprise Linux and SuSE Enterprise Linux Operating Systems. Navigate to the “Manage ISO Resources” section and upload the ISO you wish to use as the base OS of your appliance. Step 2: Upload the Stingray RAS file The next step is to upload the Software Bundle (RAS file) to the ICCT server. Navigate to the “Build and Manage software Bundles” section and click on the import icon. The RAS file will need to be available either at a URL accessible by the ICCT server, or uploaded to the local file system of the ICCT server itself. Step 3: Create your new BaseOS Image At this point we have an ISO and our software bundle imported. However before we can use the software bundle we must have an image imported into ICCT which we can extend. We’re going to create a new image from the ISO; however you may chose to import a pre-existing Linux image if you have one. If you import a pre-exising image then you can skip to step 4. Navigate to “Build and Manage Images”. Click on the “New Image” icon and then select create from ISO On the next screen you will need to enter some information about the new image we are creating. You can give it a name such as “RHEL BaseOS”, A universal ID such as com.riverbed.rhel62.baseOS, a version (eg 6.2.0), and a description. You will next need to provide the ISO resource which we uploaded earlier, and a kickstart or AutoYAST file. You can download the default KickStart file from ICCT and then extend it. If you intend to make use of the Stingray kernel modules then I would recommend adding the following applications:  gcc, make, perl, kernel-devel. Next you can pick the hardware parameters for the new image. A summary is displayed on the final screen, click done to complete the image creation process. Step 4: Extend the BaseOS Image Now that we have a Base OS configuration, the next step is to add our software bundle and set the installer parameters. Select your new Base OS image in the left hand pane and then click the Extend icon Enter appropriate information for your Stingray Virtual Appliance: Name, Universal ID, Version and Description, and then click Create. Select the new Image in the left hand pane. Click the “Start Editing” Button. Scroll down to the “Software Bundles” and click the “Add” button. Add the Stingray software bundle. Once you have added the bundle you have the option of chosing a different version of the software to install. Expand the properties and change the locations of the installers to the desired versions. The Deploy options can be ignored as they are used at instance deployment not in the initial install phase. Once you are happy with your installation options, Click “Done Editing” and “Save”. Click on the “Synchronize” button to have ICCT deploy your new image and run through the installation process. Once the image is synchronized you will be able to see the details in the “Virtual System” section of the image details pane. At this point you can log into the Virtual System via SSH and confirm that the installer completed successfully by viewing the “/var/log/provision.log” file. This is also a good time to apply any OS patches and/or add additional software. Note:  On RHEL 6.2 the modules may fail to install because the shipped gcc does not match the compiler used to build the kernel (not on the original disc). Feel free to run a yum update at this point and rerun the Stingray modules installer. The provision log will tell you the temporary directory where they were downloaded. Once you are happy with the system, return to ICCT and click “Capture”. ICCT will shut down the VM and capture it as an appliance image, once this step completes you can export the image into PureFlex System Manager or Smart Cloud Entry. Your custom Stingray appliance is ready.
View full article
This Document provides step by step instructions on migrating Cisco ACE configuration to Stingray Traffic Manager.
View full article
Stingray's TrafficScript rules can inspect and modify an entire request and response stream. This provides many opportunities for securing content against unauthorized breaches. For example, over a period of 9 months, a hacker named Nicolas Jacobsen used a compromised customer account on T-Mobile's servers to exploit a vulnerability and leach a large amount of sensitive information (see http://www.securityfocus.com/news/10271). This information included US Secret Service documents and customer records including their Social Security Numbers. This article describes how to use a simple TrafficScript rule to detect and mask out suspicious data in a response. The TrafficScript rule Here is a simple rule to remove social security numbers from any web documents served from a CGI script: if( string.contains( http.getPath(), "/cgi-bin/" ) ) {    $payload = http.getResponseBody();    $new_response = string.regexsub( $payload, "\\d{3}-\\d{2}-\\d{4}",                             "xxx-xx-xxxx", "g" );    if( $new_response != $payload )       http.setResponseBody( $new_response ); } Configure this rule as a 'Response Rule' for a virtual server that handles HTTP traffic. How it works How does this simple-looking TrafficScript rule work?  The specification for the rule is: If the request is for a resource in /cgi-bin/, then: mask anything in the response that looks like a social security number. In this case, we recognize social security numbers as sequences of digits and '-' (for example, '123-45-6789') and we replace them with 'XXX-XX-XXXX'. 1. If the request is for a resource in /cgi-bin/: if( string.contains( http.getPath(), "/cgi-bin/" ) ) { The http.getPath() function returns the name of the HTTP request, having removed any %-encoding which obscures the request. You can use this function in a request or response rule.The string.contains() test checks whether the request is for a resource in /cgi-bin/ . 2. Get the entire response: $payload = http.getResponseBody(); The http.getResponseBody() function reads the entire HTTP response. It seamlessly handles cases where no content length is provided, and it dechunks a chunk-transfer-encoded response - these are common cases when handling responses from dynamic web pages and applications. It interoperates perfectly with performance features like HTTP Keepalive connections and Pipelined requests. 3. Replace any social security numbers: $new_response = string.regexsub( $payload, "\\d{3}-\\d{2}-\\d{4}",                             "xxx-xx-xxxx", "g" ); The string.regexsub() function applies a regular expression substitution to the $payload data, replacing potential social security numbers with anonymous data. Regular expressions are commonly used to inspect and manipulate textual data, and Stingray supports the full POSIX regular expression specification. 4. Change the response: if( $new_response != $payload )    http.setResponseBody( $new_response ); The http.setResponseBody() function replaces the HTTP response with the supplied data. You can safely replace the response with a message of different length - Stingray will take care of the Content-Length header, as well as compressing and SSL-encrypting the response as required. http.setResponseBody() interoperates with keepalives and pipelined requests. In action... Here is the vulnerable application, before (left) and after (right) the TrafficScript rule is applied: Masking social security numbers with a string of 'XXX' Summary Although Stingray is not a total application security solution (look to the Stingray Application Firewall for this), this example demonstrates how Stingray Traffic Manager can be used as one layer in a larger belt-and-braces system. Stingray is one location where security measures can be very easily added - perhaps as a rapid reaction to a vulnerability elsewhere in the network, patching over the problem until a more permanant solution can be deployed. In a real deployment, you might do something more firm than masking content.  For example, if a web page contains unexpected, sensitive data it might be best just to forcibly-redirect the client to the home page of your application to avoid the risk of any sensitive content being leaked.
View full article
Here (attached) is a library that uses TrafficScript array and hashes to provide another new data structure, the set: an unordered collection in which an element occurs either once or not at all. An example use would be "words I have seen on the page". The trick to implementing this is to realise that TrafficScript already has an efficient set implementation: the hash (associative array). Specifically, you can put your data in the keys of the hash and use an arbitrary constant as the value. This means that inserting, deleting and checking membership of the set are all fast operations. While you could use that trick directly on an ad-hoc basis in individual rules, this library will improve readability and provide some type checking. If you're curious and use lang.dump($some_set) to inspect the data structure, you'll see something like this (note that the order of hash elements is arbitrary): [ "type" => "set", "values" => [ "foo" => 1, "123" => 1, "bar" => 1 ] ] One limitation of this structure is that only scalars can be members of sets, since only scalars can be hash keys. In this library, if you insert an array, each element will be inserted, and if you try to insert a hash, you'll get a warning and nothing will be inserted. The library includes the following functions: set.new() Returns a new (empty) set. set.destroy( $set ) Destroy a set. set.insert( $set, $value ) Insert a value (or another set or an array of values) into the set. set.remove( $set, $value ) Remove a value (or set or array of values) from the set. set.contains( $set, $value ) Check if the set contains a particular value. set.toarray( $set ) Return all the values in the set. set.empty( $set ) Empty a set. set.union( $a, $b ) Returns the set of elements that are in $a or $b. set.intersection( $a, $b ) Returns the set of elements that are in $a and $b. set.difference( $a, $b ) Returns the set of elements that are in $a and not in $b. set.count( $set ) Count the number of items in the set. set.subseteq( $a, $b ) Check if $a is a (non-strict) subset of $b. set.superseteq( $a, $b ) Check if $a is a (non-strict) superset of $b. To use it, add the library to your TrafficScript rules catlog, and then, in another rule, use: import libSet.rts as set; and all the 'set' functions above will be available. Here's an example of how you could use it. This rule will expect the words in $target to occur somewhere on the page, and write a log line if any of them are missing. import libSet.rts as set; $ctype = http.getResponseHeader( "Content-Type" ); if( ! string.startswith( $ctype, "text/html" ) ) break; $target = set.new(); set.insert( $target, ["riverbed","news","articles"] ); $used = set.new(); $words = string.split(string.lowercase(http.getResponseBody())); foreach( $w in $words ) {    set.insert( $used, $w ); } $unused = set.toarray( set.difference( $target, $used )); if( array.length( $unused ) ) {    log.info( http.getPath().": " . array.join(array.sort($unused),", ") );
View full article