November 2024 Summaries

Geoblocking is a strategy employed to control access to APIs based on geographic location, enhancing security, compliance, and performance by blocking traffic from specific regions. In the context of a weather API with blind spots over American Samoa and Iceland, geoblocking prevents the dissemination of inaccurate data by using API gateways like ngrok, which utilize geolocation registries to map IP addresses and filter requests. Ngrok allows for detailed geoblocking configurations through its Traffic Policy engine, using Common Expression Language (CEL) expressions to restrict or permit access based on country codes, cities, or even specific endpoints. This method, while effective, requires consideration of false positives, performance impact, and the balance between compliance and user accessibility. For those looking to implement geoblocking, ngrok offers a robust set of tools and documentation to facilitate the integration of geolocation data into API management.

The new phase-based approach to ngrok's Traffic Policy engine replaces the previous inbound and outbound directions with phase-specific labels such as on_tcp_connect, on_http_request, and on_http_response, offering more granular control over traffic management. This update allows users to configure actions at specific stages in the connection lifecycle, enhancing clarity and flexibility in handling traffic, particularly for security measures like blocking unwanted connections early at the transport layer or managing TLS termination. The changes include updates to the Traffic Policy API, agent configuration files, SDKs, and the Kubernetes Operator, ensuring greater consistency and ease of management across the platform. Users are encouraged to transition to the new format to leverage these advanced capabilities, as the traditional inbound and outbound phases will eventually be deprecated. The improved system is designed to align with real-world scenarios, providing intuitive and precise traffic management solutions.

Ngrok has rebranded its "tunnels" as "agent endpoints" to better align with industry standards and existing terminology used in its dashboard and API, introducing changes in the agent's configuration file and command-line interface (CLI). With version 3.16.0 of the agent, a new configuration file format (version 3) has been launched, offering a unified approach to terminology and configuration across the CLI and configuration files for enhanced clarity and consistency. The transition involves collapsing domain and protocol fields into a single URL field and using traffic policies for more flexible management, while endpoints now take precedence over tunnels in configuration files. Despite the deprecation of version 2 configuration files and certain CLI flags, they remain operational for compliance with the agent version support policy, with full removal planned in a future major release. Users are encouraged to upgrade to the latest version to access new features, such as specifying network addresses with a unified --url flag and adding custom information with --description and --metadata flags, and are invited to provide feedback through the ngrok community repository.

The ngrok Traffic Policy module allows developers to create flexible and expressive rules for controlling traffic and configuring complex routing topologies. To make it easier to experiment with and learn about these rules, ngrok introduces a custom-response action that can be used to return hardcoded responses from the ngrok network without requiring backends or upstream services. This allows developers to quickly test and validate their Traffic Policy rules in a simple environment. By using this custom response as a terminating rule, masquerading as a functional upstream service and connected ngrok agent, developers can develop and test additional rules at will. The custom-response action can be used for various purposes, such as returning custom HTML maintenance pages or testing load balancing scenarios with random integers and custom responses. When ready to take the developed Traffic Policy rules into production, they can be replaced with real actions, allowing for more advanced features like JWT validation, rate limiting, and internal endpoint routing.