> For the complete documentation index, see [llms.txt](https://waap.docs.link11.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://waap.docs.link11.com/v2-release-notes/version-2.14.md). # Version 2.14 2020–07–20 ## Online Documentation \- [Product Manual for v2.14](https://gb.docs.reblaze.com/v/v2.14/)\ \- [Mobile SDK](https://gb.docs.reblaze.com/v/mobile-sdk/) ## What’s New ### **Tag-based processing** Version 2.14 introduces a new [tag-based traffic flow](https://gb.docs.reblaze.com/v/v2.14/product-walkthrough/security/concepts) for Reblaze. Some tag-based processing occurred within previous versions of Reblaze, but the new system is more powerful, more thorough, and more customizable than before. Each incoming request receives a number of [tags](https://gb.docs.reblaze.com/v/v2.14/tags). There are different types of tags: * **Automatically generated**. Reblaze automatically assigns several tags to each request. Example: the originating ASN. * **Externally sourced**, based on lists selected by the admin. Example: the admin can instruct Reblaze to assign a tag of “blacklist” if the request is found on the Spamhaus DROP list. * **Custom criteria**, defined by the admin. Example: tags can be assigned if the request’s header, cookies, or arguments match specified regex patterns. After tags have been assigned, Reblaze processes the request according to its tags. The new system is administered through several pages of the UI: primarily [Session Profiling](https://gb.docs.reblaze.com/v/v2.14/product-walkthrough/security/session-profiling), [Rate Limiting](https://gb.docs.reblaze.com/v/v2.14/product-walkthrough/security/rate-limiting), and [ACL Policies](https://gb.docs.reblaze.com/v/v2.14/product-walkthrough/security/profiles/acl-policies). ### **Expanded Rate Limiting** Version 2.14 makes Reblaze’s rate limiting capabilities more flexible and powerful. * **Attributes**: Requests can be rate-limited based on several additional attributes, most notably including the tags discussed above. Multiple attributes can be combined into a single matching condition. * **Paired Attribute**: An optional “pair with” parameter can be specified, which limits the number of unique matching-condition values that are allowed per time period. [More info is here](https://gb.docs.reblaze.com/v/v2.14/product-walkthrough/security/rate-limiting#event-criteria). Example usage: A user is allowed to access a login form from no more than two separate ASNs within one hour. * **Include/Exclude Filters**: A simpler yet more powerful means of defining which segments of the incoming traffic stream will be monitored for rate-limiting purposes. * **Actions**: Admins can now specify a wider range of actions when a rate limit is violated. * Flag the request * Modify the request with a custom header for further evaluation by the backend * Block the request with a 503 error * Block the request with a custom response and error code * Block the request and redirect to a specified URL * Issue a challenge to verify that the user is a human * Ban the requestor and block all subsequent requests for a specified time ### **Streamlined configuration** The new system incorporates and simplifies many capabilities (whitelisting, blacklisting, and more) that were previously configured across multiple pages of the UI. Other UI improvements have been made as well. ### **Cloud functions** Admins can now supply [Cloud Functions](https://gb.docs.reblaze.com/v/v2.14/product-walkthrough/security/cloud-functions): custom Lua code that can be executed during request processing. Different functions can be assigned to different locations/URLs. A function can be configured to run at four possible times: * Upon receipt of a request, before Reblaze processes it * After Reblaze has finished processing the request, before it is sent to the backend * Immediately after Reblaze receives a response from the backend * As the last action before Reblaze sends the backend’s response to the client Cloud functions are a powerful tool for extending Reblaze’s functionality. Future releases will include a variety of pre-written functions and templates. ### **Trusted source definitions** The UI now provides the ability to specify ranges of IP addresses which are trusted for providing forwarded IP addresses in the X-Forwarded-For (XFF) header: for example, the load balancers in front of Reblaze, or a CDN. ### **Customized cacheing behavior** Previously, the UI offered a variety of Cache Operation Modes for customizing Reblaze’s caching behavior and the instructions sent to the client. These capabilities have been moved to Cloud Functions. ### **Increased granularity** Reblaze now offers more precise control over a number of capabilities. The list includes: * **Active Mode vs Reporting Mode**: Admins can separately enable/disable enforcement of ACL Policies, Rate Limiting, and WAF processing for individual URLs/locations. * **Frontend Timeouts and Static Rate Limits**: Previously, these were planet-wide settings; they are now configured on a per-application basis. * **Backend Configuration**: * “Backend services” (groups of origin/upstream servers) can now be defined. Their parameters (transport protocol, load balancing stickiness, etc.) are configured separately * Individual locations/URLs within an application can send traffic to different backend services. * **Mobile SDK**: The UI now provides the ability to customize various parameters for users of the Mobile SDK, including the secret key, verification variable, and more. ### **Custom error pages** Admins can customize the content of pages returned to requestors when requests are rejected or blocked, for a variety of different error codes. ### **Backwards compatibility** Some features (such as Dynamic Rules) have been deprecated, but are still being supported for now. *It is recommended that admins implement all future configurations using the new tag-based system*. ### **New version of Openresty** ## Fixes * Args analysis: Fixed an Out of Memory error. * Dashboard: Fixed an issue that prevented the display from being filtered for unrecognized host headers. * Dashboard: Fixed an issue where the graphed time period did not match user-selected time frame. * DNS: When an app is deleted from Reblaze, its DNS record is now deleted as well. * Domains: Fixed an issue validating apex domains with suffixes longer than three characters. * Logs: Fixed an issue where headers/cookies/arguments were not being pushed to the logs. * Mobile: Fixed an issue where invalid cookies were not handled correctly when the user changes their IP address during a session. * Passive bot challenges: fixed an issue where error code 500 was being returned. * Publishing: Fixed an issue where success or failure of a Publish action was not being shown. * Redis: Optimized connection pools to eliminate latency in high-traffic situations. * Various: Long lists are now alphabetized (e.g., DNS records).