# Configuration

`Event Tokenizer` works mainly through client-side and server-side integration rather than through a large config file.

To use it correctly, you must attach tokenizer validation to every server event you want to protect.

### How Protection Works

The protection flow is based on two parts:

* client-side token retrieval
* server-side token validation

A protected event is only considered valid if the token provided by the client matches the token expected by the server.

***

### Client Integration

Add this code to your client resource:

```lua
local hiddenKey = nil
local function GetToken()
    return exports['msk_tokenizer']:GetToken(hiddenKey)
end

RegisterNetEvent('msk_tokenizer:clientReady', function(code)
    CreateThread(function()
        if code then
            local loadScript = load(code)
            function SetKey(value)
                hiddenKey = value
            end
            if loadScript then
                loadScript()
            end
        end
    end)
end)
```

#### `hiddenKey`

This value is injected automatically and should not be set manually.

```lua
local hiddenKey = nil
```

#### `GetToken()`

Returns the current valid token for the player.

```lua
local function GetToken()
    return exports['msk_tokenizer']:GetToken(hiddenKey)
end
```

Use this function every time you trigger a protected server event.

***

### Triggering Protected Events

When calling a protected server event, pass the token as the first argument.

```lua
TriggerServerEvent('myResource:doSomething', GetToken(), arg1, arg2)
```

This is required for every protected event.

***

### Server Validation

At the beginning of your protected server event, validate the token:

```lua
RegisterServerEvent('myResource:doSomething', function(token, arg1, arg2)
    local _source = source

    if not exports['msk_tokenizer']:secureServerEvent(_source, token) then
        return
    end

    -- safe logic here
end)
```

#### `secureServerEvent(source, token)`

This export validates the token for the current player.

```lua
exports['msk_tokenizer']:secureServerEvent(_source, token)
```

If validation fails:

* the event is rejected
* the player can be banned automatically
* the action can be logged

***

### Token Rotation

Tokens rotate automatically to improve security.

Rotation happens:

* after every valid protected server event
* periodically over time when rotation is queued

This helps prevent token reuse and replay-based abuse.

***

### Ban Behavior

Invalid token usage can trigger an automatic ban through `Core.BanPlayer`.

#### Main Server Behavior

Ban enforcement is only active when the `servertype` convar is set to:

```lua
setr servertype "main"
```

#### Development Server Behavior

On development servers, tokens are still validated, but bans are not enforced. This allows safe testing without banning developers during setup.

***

### Replay Protection

The system also protects against repeated or duplicated event usage.

Attempting to reuse an invalid or outdated token can result in immediate punishment depending on your server type and enforcement settings.

***

### Best Practices

* Protect every sensitive server event
* Always validate the token before running any event logic
* Always pass the token as the first argument
* Do not expose or rewrite the injected key logic
* Test protected events on a development server before moving them to production

***

### Notes

* Ban handling is performed through `msk_bridge`
* No external ban system is required
* Token rotation is automatic
* Invalid token usage is treated as suspicious behavior
* Protection must be added manually to each server event you want to secure


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://mskscripts.gitbook.io/mskscripts/general-information/msk-tokenizer/configuration.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.