-
-
Notifications
You must be signed in to change notification settings - Fork 224
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Request] Solve Captcha in private Chat (DM) and userbots waves attack #119
Comments
What about: the following to protect against bot waves. :waiting channel
:main chat
|
That solution requires joincaptchabot to has full privileges in groups to remove and create new join links on each user join the group (otherwise, a malicious user can get the invite link of the main group after solving manually the captcha in waiting group and then bypass the waiting group with userbots that directly joins the main group). And Admins must not modified invite links manually, that could break the correct Bot functionality (too complex setup for Admins of a group, they won't be able to do it right). Of course, any solution must be able to be used for both, private and public groups, a solution that just works in private groups are not valid. |
I guess the main issue here is that if I post a TG group invitation link on a social media platform, I'll get hundreds of joining within a few minutes. An existing member of the group, if already viewing the contents of the group, will suddenly see lots of the captcha messages from all the new users and they will disappear after they have solved it. This is very annoying. I've no idea how this can be solved as I've seen several other captcha implementations that have exactly the same problem. This is a drawback of TG that may not even be solvable unless they have a way to send a private message to target user id within a group chat. |
I haven't tried this implementation or read the code to see the workings of it, but the description of it sounds promising. |
Wow, didn't know about that fork, yeah it is really nice I will take a look into it... However, it talks about make group private, so maybe it just can be used on private groups and not publics, and maybe all my previous analysis regarding that solution apply here:
|
Sorry, don't mind me sending my code: As below, I already solve this issue by adding multiple captcha (Including My code should be clean enough so that you can review what's going on there. |
Solve Captcha in private chat (DM)
Description
Some users ask if it is possible to make the Bot send the captcha challenge to new join members through DM (Direct Messages) in private chat instead of the group where the member joins.
Context
Currently, the Bot ask and send the captcha challenge process inside the group where a member join. To keep a clean group, the Bot delete the captcha process messages automatically after a while.
Regarding make the captcha process by DM (Direct Message) in a private chat with each new user: There is a restriction from Telegram that doesn't allows a Bot account (like captchabot) to start a private chat with an user, it always needs that the user have started the private conversation with the Bot before. If am not wrong, what Rose do is send a message in the group telling the new user to press a button that send it to a private chat with Rose, because internally that button press make the user to start the private conversation with the Bot (it is like send a DM /start command to the Bot). So the only way for JoinCaptchaBot could be the same, send a message to the group with a button to tell and ask the user solve the captcha in DM, however, as you can see, it doesn't really help, because the Bot must send a message in the group with that Button, so we are just replacing the captcha image message to a text with a button message, the chat still gonna be noisy with this messages.
Current Bot code is oriented to handle users captcha process inside groups, and move that logic to be done through DM requires a lot of work. Also, not all users want the DM thing, so both modes must be available and handled, increasing complexity in code maintainability without seeing any good benefit/advantage on doing it.
The text was updated successfully, but these errors were encountered: