liminiens / grinder Goto Github PK

View Code? Open in Web Editor NEW

22.0 3.0 7.0 236 KB

Telegram bot for chats administration

License: MIT License

F# 93.18% C# 5.33% Dockerfile 1.49%

grinder's Introduction

Grinder

Telegram bot for chats administration.

Configuration and build

Install Net5 SDK
Open project with Rider/VS 2019 and run build
or use dotnet cli

dotnet build

Running

About configuration you can read below in Configuration section

Using a Docker container

You can just spawn new container with bot from keroosha/grinder repo We have x86-64 and ARM32 containers for a bot, check tag section at docker hub page

use docker env file to configure a bot

docker run -d --env-file config.env keroosha/grinder:latest

or attaching dir with predefined appsetings.json

docker run -d --mount /path/to/dir/with/appsettings:/etc/grinder keroosha/grinder:latest

Using a docker-compose

You can use already configured docker-compose.yml as example but, some action required before starting:

Create a config.env file with environments or dir with appsettings.json
Change data path in docker-compose.yml and attach configurations to container
Setup database
You are ready to go! ᕕ( ᐛ )ᕗ

Localy

Just create a launch configuration in your favorite IDE and don't forget about configuration and you will be fine :>

Configuration

You can choose two ways to configure grinder but keep in mind about configuration priorities in configuration provider:

Order of Precedence when Configuring ASP.NET Core

External appsettings.json

appsettings.json

{
    "Bot": {
        "Token": "test",
        "ChannelId": 111,
        "AdminUserId": 123,
        "Socks5Proxy": {
            "Hostname": "Hostme",
            "Port": 1337,
            "Username": "User",
            "Password": "Secrete"
        },
        "ChatsToMonitor": [
            "Sample",
            "Text"
        ],
        "AllowedUsers": [
            "Pasha",
            "Technique"
        ]
    }
}

Attaching appsettings.json

You can attach dir with customized appsettings.json to /etc/grinder/ volume

Environment Variables

Example of env file:

# Socks5Proxy - Socks5 proxy configuration
Grinder_Bot__Socks5Proxy__Port=1337
Grinder_Bot__Socks5Proxy__Hostname=Hostme
Grinder_Bot__Socks5Proxy__Password=Secrete
Grinder_Bot__Socks5Proxy__Username=User

# AllowedUsers - users, who will be able to execute commands in chats from ChatsToMonitor
Grinder_Bot__AllowedUsers__0=Pasha
Grinder_Bot__AllowedUsers__1=Technique

#ChatsToMonitor - chats where bot will read messages and replies
Grinder_Bot__ChatsToMonitor__0=Sample
Grinder_Bot__ChatsToMonitor__1=Text

#AdminUserId - telegram user id who will be able to send private messages to bot
Grinder_Bot__AdminUserId=123

# ChannelId - telegram channel id where bot will write command logs
Grinder_Bot__ChannelId=111

# Token - bot api token
Grinder_Bot__Token=test

Bot commands

Ban

While writing in any chat from ChatsToMonitor:

@botusername @user1 @user2 ... ban <time>

Where time can be combination of this:

Days: <integer> day(s)

Minutes: <integer> min(s)

Months: <integer> month(s)

Time fractions can appear in any order and once.

This will ban user in all chats from ChatsToMonitor

Examples:

@botusername @user1 @user2 ... ban 1 month 12 minutes

@botusername @user1 @user2 ... ban 6 minutes

@botusername @user1 @user2 ... ban 1 month 5 minutes
Unban

While writing in any chat from ChatsToMonitor:

@botusername @user1 @user2 ... unban

This will unban user in all chats from ChatsToMonitor
Ban on reply

While writing a reply to user in ChatsToMonitor:

@botusername ban

This will permaban user in all chats from ChatsToMonitor
Database update

This can execute only user AdminUserId.

This will update a database mapping of usernames to userid's. You have to send a file in a private message to bot.

File structure:
```
[
  {"UserId": <telegram user id> ,"Username": "username without at sign"},
  ...
]
```
File can be generated by running a project Export tool on path src\Grinder.ExportTool\.

grinder's People

Contributors

Stargazers

Watchers

Forkers

stripedl ahydrax keroosha szer fsharplang-ru yogurtthehorse highnetfather

grinder's Issues

unban command still bans people!

As I can see now, the unban command (@botname @username unban) still bans people, and then reverts its action afterwards.

Consider this sad story:

The user is banned via @botname ban
Afterwards, the user was unbanned manually due to unrelated problems with bot unban
And when we fixed these problems and called @botname @username unban, first thing it does is… ban the user again!
Afterwards it has unbanned the user.

Automatic database update on ban

Extracted from #13 (comment):

We could update the nickname database whenever we ban something (we always know the nickname when we ban a user).
We could add two unban modes:
- unban by message (when I reply to a message from a banned user with "unban" command, bot gurinderu-sama should react accordingly)
- unban by user id (I could gather the id manually or we could add a corresponding mode to the bot itself)

Retrospective ban by the message text factor

Consider this scenario (sadly, very typical these days):

Spambot1 joins chat1
Spambot2 joins chat2
Spambot3 joins chat3
All three bots send the same message text to the respective chats

Currently, I need to manually visit all the chats and invoke @dotnet_vahter_bot ban separately (because the bots are different users).

What I want is Grinder to automatically ban the Spambot2 and Spambot3 after I shown it the message text of Spambot1.

How to achieve that:

Whenever Grinder starts, it should read last N (N should be configurable limit, with a sensible default of, say, 25) messages in each of the connected chats, and store these messages in memory.
When a message arrives in any of the connected chats, Grinder should drop the earliest message saved and save a new one (FIFO order).
When a ban request arrives as a reply on the spam message, Grinder should compare that spam message with the saved messages from each of the connected chats. If it finds any match, it should delete the matched message and ban the corresponding users in each of the chats the message was posted.
The spam message should be saved to a separate global in-memory storage with another configurable limit of M (e.g. up to 10 messages, we don't need much here because of their variety).
When a new message is registered in any of the connected chats, Grinder should compare it with the M globally stored spam messages, and ban the user/delete the message on match.

Keyword ban

Grinder should be able to ban users based on a configurable list of keywords. Only the first message of a user (after joining the chat) should be examined for these keywords.

Make command syntax more strict

Bot should react on the following message:

@dotnet_vahter_bot ban

Bot should not react on the following messages:

`@dotnet_vahter_bot ban`
Напиши @dotnet_vahter_bot ban

Otherwise it becomes hard to explain the bot functioning to new admins.

Add CI and deployment to Docker Hub

Layered ban and admin lists

We need to include layers of banlists.

Consider we have three chats: chat1 and chat2 belong to the main network, and chat3 is a side chat.

We need to change Grinder so chat3 is semi-isolated from the main network: admins of the main network are also admins in chat3, but chat3 admins aren't admins in chat1 and chat2. People banned in chat1 and chat2 are also automatically banned in chat3, but not the other way around.

In other words, chat3 should automatically receive admins and bans from the main network, but the main network shouldn't receive admins and bans from the chat3.

unban command doesn't work

See https://t.me/dotnettalks/576001

Add unit tests

Currently the code is untestable. This should be fixed.

Filter on chat ids instead of chat usernames when listening to new messages

Special storage for spam messages

For purpose of further analysis it would be useful to keep deleted spam messages and images in a separate special purpose storage.

We have some possible uses for such a base (e. g. use machine learning to analyze the messages), but absence of such data stops us completely.

It is important for the storate

to be available for external researchers
to not occupy too much space (there should be a size limit)
to not use Telegram for data transmission (e. g. not just simply forward the spam messages to a separate channell)

Some elaboration on the last item: I fear that the bot could be banned by Telegram if it will start forwarding the spam messages somewhere, because Telegram could detect that action as spam itself.

Delete entering message and last N messages

Whenever someone is banned for spam, let's delete a couple of last messages from that user (by default, last three). "User entered the chat" message should also be included into that count and deleted.

Publish on git tags

Need to extend CI pipeline to able push container with bot by git tag

Right now, CI pushes new container on new code at master branch. It might be useful create a "releases" via git tags

Forbid admins to ban other admins

Figure out the current unban problems

Based ob the latest incident, it looks like the unban command isn't functional at all. We should investigate it.

Store logs in channel

Bot should keep a special channel and forward there any messages that triggered the ban. It is useful for discovering ban history.

Short bot logs could also be kept in the channel for ease of access.

Publish x86-64 container

Right now CI pipeline builds only ARM container

Need to create new Dockerfile for x86-64 architecture and extend CI pipeline to built it

bot_config.json and development

Now everyone has to create it manually, maybe there is a way to do it better.

Please describe the database maintainership

According to the docs, there's an infamous step 3 when setting up the environment for the bot, namely, "Setup database".

@Keroosha tells that @Liminiens knows more on that matter.

@Liminiens, could you please elaborate, what kind of database setup is required before starting a bot, and what steps are required to maintain/update the database?

Failsafe mechanism on autobahn

We should add a reasonable ban limit (e.g. 10 users per hour by default) to prevent mass casualties in case the bot gets insane. Because it will, oh yes it will.