What’s New
What’s New in Web Agent 5.9.1
- Pre-authentication Cookies Are Expired Immediately After Authentication
-
In previous releases, the pre-authentication cookie,
agent-authn-tx, expired when it reached the age configured by Profile Attributes Cookie Maxage. From this release, the pre-authentication cookie expires when the first of the following events occur:-
Authentication completes successfully
-
It reaches the age configured by Profile Attributes Cookie Maxage
Expiring the cookie immediately after authentication reduces the amount of used header space, and prevents authentication errors and errors in applications that set headers.
-
- URI Fragments Persisted in Custom Login Mode
-
When the value of Enable Custom Login Mode is
2, URI fragments were previously lost during login. From this release, URI fragments in the browser are not lost after the custom login procedure.
- Post Data Preservation: Use a Single Agent Profile for Multiple Agent Instances
-
In previous releases, to correctly configure post data preservation, a separate agent profile was required in AM for each agent instance. From this release, a single agent profile can be used for multiple agent instance.
Use this feature for scalable deployments, where resources are dynamically created or destroyed.
- NGINX Plus R25
-
The NGINX Plus R25 platform is available in this release.
What’s New in Web Agent 5.9
- Keep Session Cache After Configuration Change
-
Retain Session Cache After Configuration Change is a new property to stop the agent from purging the session cache each time the agent configuration is changed. Use this property to prevent the agent from flooding AM instances with requests, when the agent configuration changes regularly, and the changes do not affect the agent authorisation decisions.
- Profile, Response, and Session Attributes Take Multiple Values
-
The following properties can now take multiple values:
In previous releases, they could take only one value.
- Reduced Authentication Requests to AM
-
The agent reads its configuration from AM in the following situations:
-
When it connects to AM
-
After a configuration change
-
When it authenticates with AM
If the AM server is flooded with requests from the agent, it can become unresponsive, causing the agents to stop functioning normally and refuse access.
In previous releases, after a configuration update each request thread retrieved the new configuration, and re-authenticated with AM.
In this release, a single request thread retrieves the new configuration, and re-authenticates with AM only if necessary. Concurrent request threads wait for the time specified by TCP Receive Timeout for the retrieving request thread to complete, and then they use the new configuration.
-