Documentation Index
Fetch the complete documentation index at: https://mintlify.com/avikekk/JackettSearchBot/llms.txt
Use this file to discover all available pages before exploring further.
Overview
JackettSearchBot implements a multi-layered authorization system to control who can access the bot. Access is controlled through a combination of permanent configuration and temporary runtime authorization.All authorization checks happen at the command level before any operations are performed.
Authorization Levels
The bot has three levels of access:- Owner - Full access including authorization management
- Authorized Users/Chats - Can use search and check commands
- Unauthorized - No access to bot commands
Owner Access
Configuring the Owner
The owner is configured via theOWNER_ID environment variable:
Owner Privileges
The owner has exclusive access to:/auth- Grant temporary access/unauth- Revoke temporary access/unauthall- Clear all temporary authorizations
- Use pagination controls on any user’s search results
- Cannot be removed via
/unauth(protected) - Always bypasses authorization checks
Finding Your User ID
To find your Telegram user ID:- Message the bot
@userinfoboton Telegram - It will reply with your user ID
- Use this number as
OWNER_ID
Authorized Users & Chats
There are two types of authorization: configured (permanent) and temporary (runtime).Configured Authorization
Permanent authorization is set via theAUTHORIZED_CHAT_IDS environment variable:
- Comma-separated list of IDs
- No spaces (or spaces are trimmed)
- Can include both user IDs and chat IDs
- User IDs: positive integers
- Group/channel IDs: negative integers
- Single User
- Multiple Users
- Users + Groups
- Empty (Owner Only)
Configured authorizations are loaded at bot startup and cannot be changed without restarting the bot.
Temporary Authorization
The owner can grant temporary access using the/auth command:
- Stored in memory only
- Cleared when bot restarts
- Can be removed with
/unauth - Can be bulk-removed with
/unauthall
- Testing access for new users
- Granting temporary access
- One-time authorization needs
- Permanent access (use
AUTHORIZED_CHAT_IDS) - Production authorization (will be lost on restart)
Authorization Process
How Authorization Checks Work
Every protected command calls the authorization check:Check Priority (First Match Wins)
- Owner check - Is the user the bot owner?
- Chat configured - Is the chat ID in
AUTHORIZED_CHAT_IDS? - Chat temporary - Has the chat been temporarily authorized?
- User configured - Is the user ID in
AUTHORIZED_CHAT_IDS? - User temporary - Has the user been temporarily authorized?
- Deny - No authorization found
Both user ID and chat ID are checked, allowing flexible authorization strategies.
User vs. Chat Authorization
User authorization:- Follows the user across all chats
- Works in private messages
- Works in any group
- Only works in that specific chat
- Any authorized user in that chat can use the bot
- Useful for authorized groups
Private Chat
Private Chat
Scenario: User messages bot directlyAuthorization check:
user_id: User’s Telegram IDchat_id: Same as user_id (private chats use user ID as chat ID)
Group Chat
Group Chat
Scenario: User sends command in a groupAuthorization check:
user_id: User’s Telegram ID (positive)chat_id: Group’s chat ID (negative)
- Authorized if user ID is authorized (works in any group)
- OR if group chat ID is authorized (any member can use)
Authorized Group
Authorized Group
Authorization Service
TheAuthorizationService manages authorization state:
Key Methods
add_authorized()
add_authorized()
remove_authorized()
remove_authorized()
clear_authorized()
clear_authorized()
is_configured_id_authorized()
is_configured_id_authorized()
is_temporary_id_authorized()
is_temporary_id_authorized()
Thread Safety
The service usesthreading.RLock() for thread-safe operations:
- Reentrant lock (same thread can acquire multiple times)
- Prevents race conditions
- Safe for concurrent command handling
Managing Authorization
Granting Access
Via/auth command (temporary):
- Explicit ID
- Current Chat
Revoking Access
Via/unauth command:
Uses same target extraction as /auth:
/unauth 123456789- Remove specific ID- Reply +
/unauth- Remove replied user /unauthalone - Remove current chat
- Owner protection:
- Configured ID protection:
Bulk Revocation
Via/unauthall command:
- Security incidents
- Access resets
- Cleanup after testing
Security Considerations
Best Practices
Access Control Patterns
Owner-Only (Strictest)
Owner-Only (Strictest)
Configuration:Result:
- Only owner can use bot
- Owner can grant temporary access as needed
- Maximum security
Trusted Users
Trusted Users
Configuration:Result:
- Owner + 3 trusted users
- Users can use bot anywhere
- Owner can add temporary users
Private Group
Private Group
Configuration:Result:
- Only works in group
-987654321 - Any group member can use bot
- Bot won’t work in other chats (except for owner)
Mixed (Flexible)
Mixed (Flexible)
Configuration:Result:
- Owner everywhere
- User
111111111everywhere - Group
-987654321members in that group only
Authorization Errors
Unauthorized access attempt:Troubleshooting
Bot Not Responding
Check authorization:- Run
/startcommand - If you see
ERROR: NOT AUTHORIZED, you’re not authorized - Contact the bot owner to grant access
Cannot Remove Authorization
Symptom:/unauth says ID is from config
Solution:
- Edit
config.env - Remove ID from
AUTHORIZED_CHAT_IDS - Restart the bot
Lost Owner Access
Prevention: Always keep yourOWNER_ID safe
Recovery:
- Stop the bot
- Edit
config.env - Correct
OWNER_ID - Restart the bot
Temporary Authorization Lost After Restart
This is expected behavior. Temporary authorizations are not persisted. Solution:- Use
AUTHORIZED_CHAT_IDSfor permanent access - Or re-authorize after restart using
/auth