Version 2.14
2020–07–20
Online Documentation
- Product Manual for v2.14 - Mobile SDK
What’s New
Tag-based processing
Version 2.14 introduces a new tag-based traffic flow 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. 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, Rate Limiting, and 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. 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: 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
https://openresty.org/en/changelog-1015008.html
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).
Last updated