[C2] Add global tokens feature for all types of link-based confirmations

[ywarnier]

We are having the opportunity to make a good thought development that will reduce the hassle for many things later on.

In order to make a clickable link in an e-mail that goes to a confirmation page of some kind, we need a "relatively secure" hash, meaning a hash that has so many combinations that it is difficult to guess.

SHA-256 has 64 characters (so an acceptable length). This generates 2²⁵⁶ combinations with a risk of collision requiring 2¹²⁸ attempts (about 3.4x10³⁸). So... safe enough for now (until quantum-resistant algorithms come around).

We also need the table to have a datetime to remember when the hash was generated and implement a maximum validity time for each hash (the table could then later be cleansed by a clear:cache or any similar mechanism).

Finally, we need a type of event we want to trigger (or a type of resource or link) and a unique ID of that resource.

Because searches are much faster on fixed-length numbers in a relational database than on strings, and because we already have a 64-characters string, we should use only fixed numbers for the rest of the table fields, so the type will be expressed as an integer and the relationship between that type field and the actual resource type should be documented (as constant) in this hashes table's entity definition.

So the table shoud look like this (roughly):

Field	Type	Null	Key	Default	Extra
id	int	NO	PRI	NULL	AUTO_INCREMENT
type	int	NO		NULL
ressource_id	bigint	NO		NULL
hash	char(64)	NO		NULL
created_at	datetime	NO		NOW()

An index should be created on type+hash.

I'm not sure if this needs to be mapped to a resource (we first need it for ticket_rel_user, which is not a resource, I believe), so if you have a better name for 'resource_id, it is welcome (maybe just item_idormapping_id`).

The entity/table should be called ValidationToken.

A new controller should be created for links like /validate/ticket/abcde to point to, where the type (ticket in this example) is not necessary but, if defined, helps the script filter the possible hashes in the ValidationToken repository. It also helps as a "friendly url" to understand what kind of validation we're giving (it can be ignored). The only important info is the last bit (abcde in this example) that contains the actual token.

The controller then checks the type (transforms the litteral type into a number through the entity constant list, then queries the table for the given type and token) and processes the action related to that type.
Once the action has been confirmed successful, it deletes the token from the table and registers an event (new type VALIDATION_TOKEN_USED) in track_e_default.

To make this easy to use from other entities, we should have a method ValidationToken::generateLink($type, $id) that returns a URL pointing to the controller.

[christianbeeznest]

Implemented a secure token validation system using SHA-256 for specific actions like ticket validation. Features include token generation, validation via unique links, basic action processing, event logging, and token deletion. The system is partially complete, with placeholder logic for ticket validation.

To test:

• Generate token: /validate/test/generate-token/ticket/12345
• Validate: Use the generated link
• Verify: Confirmation page, token removal, and event logging
• Further implementation of specific token type logic is needed.