- 14.6.4.1. Proxy Scripting Sequence During Query Injection
- 14.6.4.2. Internal Structures
- 14.6.4.3. Capturing a Connection with
connect_server() - 14.6.4.4. Examining the Handshake with
read_handshake() - 14.6.4.5. Examining the Authentication Credentials with
read_auth() - 14.6.4.6. Accessing Authentication Information with
read_auth_result() - 14.6.4.7. Manipulating Queries with
read_query() - 14.6.4.8. Manipulating Results with
read_query_result()
You can control how MySQL Proxy manipulates and works with the queries and results that are passed on to the MySQL server through the use of the embedded Lua scripting language. You can find out more about the Lua programming language from the Lua Web site.
The following diagram shows an overview of the classes exposed by MySQL Proxy.
The primary interaction between MySQL Proxy and the server is provided by defining one or more functions through an Lua script. A number of functions are supported, according to different events and operations in the communication sequence between a client and one or more backend MySQL servers:
connect_server(): This function is called each time a connection is made to MySQL Proxy from a client. You can use this function during load-balancing to intercept the original connection and decide which server the client should ultimately be attached to. If you do not define a special solution, a simple round-robin style distribution is used by default.read_handshake(): This function is called when the initial handshake information is returned by the server. You can capture the handshake information returned and provide additional checks before the authorization exchange takes place.read_auth(): This function is called when the authorization packet (user name, password, default database) are submitted by the client to the server for authentication.read_auth_result(): This function is called when the server returns an authorization packet to the client indicating whether the authorization succeeded.read_query(): This function is called each time a query is sent by the client to the server. You can use this to edit and manipulate the original query, including adding new queries before and after the original statement. You can also use this function to return information directly to the client, bypassing the server, which can be useful to filter unwanted queries or queries that exceed known limits.read_query_result(): This function is called each time a result is returned from the server, providing you have manually injected queries into the query queue. If you have not explicitly injected queries within theread_query()function, this function is not triggered. You can use this to edit the result set, or to remove or filter the result sets generated from additional queries you injected into the queue when usingread_query().
The following table describes the direction of information flow at the point when the function is triggered.
| Function | Supplied Information | Direction |
|---|---|---|
connect_server() | None | Client to Server |
read_handshake() | None | Server to Client |
read_auth() | None | Client to Server |
read_auth_result() | None | Server to Client |
read_query() | Query | Client to Server |
read_query_result() | Query result | Server to Client |
By default, all functions return a result that indicates whether
the data should be passed on to the client or server (depending on
the direction of the information being transferred). This return
value can be overridden by explicitly returning a constant
indicating that a particular response should be sent. For example,
it is possible to construct result set information by hand within
read_query() and to return the result set
directly to the client without ever sending the original query to
the server.
In addition to these functions, a number of built-in structures provide control over how MySQL Proxy forwards queries and returns the results by providing a simplified interface to elements such as the list of queries and the groups of result sets that are returned.