Resourcepack Protection
How to protect your resourcepack
Protect your resourcepack from thief
Disclaimer
There is no 100% effective way to protect resourcepack because the game must need to be able to extract it correctly to show textures.
This feature is a mitigation to avoid kids and trolls to steal your texture. Some experienced users might be able to find a way to bypass these protections.
ItemsAdder does its best to prevent this, but keep that eventuality in mind.
Every other plugin has the same limitations. It's not a limitation of ItemsAdder.
With ItemsAdder you can protect your resourcepack from unzip and thieves.
You just have to set this option in config.yml
and use /iazip
again.
If you're using an external host (like Dropbox) don't forget to reupload the pack and update the config.yml
.
protection_1
protection_1
Protect the resourcepack with a basic method.
protection_2
protection_2
Protect the pack with another layer of protection to block some other methods to unzip the pack.
Showcase
This is a funny meme showcase of what the user will see when they try to steal your data. But this is actually what the user will see, a group of corrupted files and folders.
Protect self-host resourcepack from DDoS attacks
Disclaimer
There is no 100% effective way to protect resourcepack because the game must need to be able to extract it correctly to show textures.
This feature is a mitigation to avoid kids and trolls to try to slowdown your server. ItemsAdder does its best to prevent this, but keep that eventuality in mind.
This feature is available only on ItemsAdder 4.0.8
protection
protection
This section contains security settings to prevent abuse and unauthorized requests.
block_non_game_requests
block_non_game_requests
Default: false
Blocks requests made by visiting the resource pack URL from a browser or an automated service (for example, a console command used to DDoS your server).
rate_limit
rate_limit
This setting helps prevent frequent requests that are likely automated, such as a DDoS attack.
enabled
Default: true
Determines whether request rate limiting is active.
max_requests
Default: 3
The maximum number of allowed requests within the period_seconds
timeframe before triggering restrictions.
period_seconds
Default: 2
The time window (in seconds) in which requests are counted. If a client exceeds max_requests
within this period, it counts as a failed attempt.
cooldown
cooldown
This section controls how long a client’s requests will be ignored after repeatedly failing the rate limit check.
Example: If a user sends more than 3 requests within 2 seconds, and does this 5 times, their future requests will be blocked for 30 minutes.
enabled
Default: true
Determines whether clients exceeding the request limit should be temporarily ignored.
duration_minutes
Default: 30
The duration (in minutes) for which the client’s requests will be ignored after exceeding the trigger_on_failed_times
limit.
trigger_on_failed_times
Default: 5
The number of times a client can exceed the request limit within a short period before triggering the cooldown.
Last updated
Was this helpful?