Global Key-Value Table Support for Lua Scripts (8.0.3)

FortiWeb 8.0.3 adds support for global key-value tables in Lua scripts, allowing data to persist across transactions within the same server policy. This capability enables developers to implement more advanced logic in their scripts by storing shared information that can be accessed by multiple worker threads during processing.

Enhancements

Global key-value table support in Lua

FortiWeb now provides shared in-memory tables that Lua scripts can use to store and retrieve data across requests handled within the same server policy.

New Lua API functions for table management

FortiWeb introduces the following functions, which allow developers to create and maintain global key-value tables:

• SVRPOLICY:shared_table_create(table)

• SVRPOLICY:shared_table_destroy(table_name)

• SVRPOLICY:shared_table_insert(table_name, key, value, expire_seconds)

• SVRPOLICY:shared_table_lookup(table_name, key)

• SVRPOLICY:shared_table_delete(table_name, key)

• SVRPOLICY:shared_table_dump(table_name, index, count)

• SVRPOLICY:shared_table_entry_count(table_name)

Enables advanced scripting use cases

These functions allow Lua scripts to maintain shared state across requests, supporting scenarios such as tracking activity, maintaining counters, storing custom session information, or implementing logic that depends on data accumulated over time.

Using Global Key-Value Tables in Lua Scripts

Developers can use the new API functions within any server policy that has Lua scripting enabled. The functions support:

• Table creation during policy initialization — Tables can be created in the RULE_INIT event using shared_table_create.

• Stateful data access across all events — Lookup, insert, delete, and count operations are available in all Lua events, including HTTP_REQUEST, HTTP_RESPONSE, and others.

• Automatic table cleanup — Tables can be destroyed in the RULE_EXIT event using shared_table_destroy, ensuring that state is reset when the policy configuration changes.

Because these tables operate in shared memory within a policy, scripts running on different server policies cannot access each other's data, ensuring proper isolation.