Adding documentation about the handshake validation process

docs/communication.md

@@ -47,7 +47,11 @@ The application can define a dictionary of compressed routes before starting, th
 
 ### Handshake
 
-The first operation that happens when a client connects is the handshake. The handshake is initiated by the client, who sends informations about the client, such as platform, version of the client library, and others, and can also send user data in this step. This data is stored in the client's session and can be accessed later. The server replies with heartbeat interval, name of the serializer and the dictionary of compressed routes.
+The first operation that happens when a client connects is the handshake. The handshake is initiated by the client, who sends information about the client, such as platform, version of the client library, and others, and can also send user data in this step. This data is stored in the client's session and can be accessed later. The server replies with heartbeat interval, name of the serializer and the dictionary of compressed routes.
+
+In order to enforce specific requirements, validations can be performed on the data submitted by the client. These validations server as a means to verify that the client is adherent to predefined server rules. By that if the client does not comply with the specified criteria, access to the server capabilities can be restricted.
+
+You can find more about the handshake validation [here](./handshake-validators.md).
 
 ### Remote service
 

docs/handshake-validators.md

@@ -0,0 +1,29 @@
+Handshake Validators
+=====
+
+Pitaya allows to defined Handshake Validators.<br />
+
+The primary purpose of these validators is to perform validation checks on the data transmitted by the client. The validators play a crucial role in verifying the integrity and reliability of the client's input before establishing a connection.
+
+In addition to data validation, handshake validators can also execute other custom logic to assess the client's compliance with the server-defined requirements. This additional logic may involve evaluating factors such as authenticating credentials, permissions, or any other criteria necessary to determine the client's eligibility to access the server.
+
+### Adding handshake validators
+
+To ensure the effective utilization of these validators, they should be added to the `SessionPool` component. As a result, each newly created session within the `SessionPool` will automatically incorporate the designated validators.
+
+Once the handshake process is initiated, the validators will be invoked to execute their validation routines.
+
+```go
+cfg := config.NewDefaultBuilderConfig()
+builder := pitaya.NewDefaultBuilder(isFrontEnd, "my-server-type", pitaya.Cluster, map[string]string{}, *cfg)
+builder.SessionPool.AddHandshakeValidator("MyCustomValidator", func (data *session.HandshakeData) error {
+	if data.Sys.Version != "1.0.0" {
+		return errors.New("Unknown client version")
+	}
+
+	return nil
+})
+```
+
+As a result of the validation process, if an error is encountered, the server will transmit a message to client within the code 400. This code emulates the widely recognized HTTP Bad Request status code, indicating that the client's request could not be fulfilled due to invalid data. Otherwise, if the validation process succeeds, the server will dispatch a message to client containing a code 200, mirroring the HTTP Ok status code.<br />
+**Is important to mention that, when there are many validator functions, the validation will stop as soon it encounters the first error.**