-
Notifications
You must be signed in to change notification settings - Fork 16
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
Rate limiter par ip #1554
Comments
This could be a good idea. But these bots are probably using services that rotate IPs automatically for them as well... I think even using a service like "Google Cloud Functions" automatically gives you different IP addresses when you make an outgoing request. What could work well, is if you ensure that the same IP is used for every request involved in a single booking from start to finish- this will make it harder because bots will need to ensure they maintain the state of multiple requests over a single IP, which can be quite technical depending on what service they are using to make the requests. This combined with the rate-limiting could be one part of a good defense. [google translate] Cela pourrait être une bonne idée. Mais ces robots utilisent probablement aussi des services qui font pivoter automatiquement les adresses IP pour eux... Je pense que même l'utilisation d'un service comme "Google Cloud Functions" vous donne automatiquement différentes adresses IP lorsque vous effectuez une requête sortante. Ce qui pourrait bien fonctionner, c'est si vous vous assurez que la même IP est utilisée pour chaque requête impliquée dans une seule réservation du début à la fin - cela rendra la tâche plus difficile car les bots devront s'assurer qu'ils maintiennent l'état de plusieurs demandes sur une seule adresse IP, ce qui peut être assez technique selon le service utilisé pour effectuer les requêtes. Ceci, combiné à la limitation du débit, pourrait être une partie d'une bonne défense. |
I thinks that the actual bots are hosted on vps with a "normal" provider like OVH. Those provider dont offer ip rotation. I am 100% with you for the "dual" protection, it would be very technical to break it and not very difficult to implement. |
If they are using a service like you say- even more reason to implement this! Because then you can save an IP to a specific successful booking and not allow that IP to be used again in any other bookings (for at least a few days)- this would force them to spend more on services offering rotating IPs (with the added technical ability to be able to re-use the same one over a bunch of separate requests). I hate all these bots in the French admin systems- I'm a foreigner here, so to book for my "Titre de Sejour" it was the same pain! Now I'm trying to book my license and I have to deal with it again 😖 - I hope the devs can find some creative solutions to this, I know it can be difficult to fight. |
I know that the biggest bot is hosted on a simple VPS at OVH, because when a fire was declared in there datacenter the bot was offline for quite a long time. I think that IP limitation is the best way to fight them. The ip could be "banned" of the place taker route while the exam is reserved (if the user cancel his place, the ip could be unbanned so he can pick an other one after the 45 days penalty) |
Hello all, Is there any staff members here ? Please, could we get some update about your roadmap to mitigate this bot nightmare ? Also, is this project open to free contributions ? Can we join the development team ? I would be volunteer if it can help fixing the platform... |
Bonjour, Il est donc vraisemblable que les administrateurs de ce repository refusent toute refonte de l'architecture du système d'ici là, et préfèrent laisser pourrir la situation pour les 5 prochains mois (notamment parce que les places disponibles sont de toutes façons toutes saturées jusqu'à l'été). Bienvenue dans la StartupNation ! |
Les bots profitent beaucoup de candlib pour "voler" les places aux honnêtes candidats. Pour contrer les bots il serait très simple de mettre un middleware sur la route de l'api qui gère la prise d'une place d'examen, celui-ci vérifiera l'ip source (qui peut être stockée dans la requête envoyée à l'api), si celle-ci a déjà prise une place d'examen, alors elle est "banni" de la route de prise de place pendant 10H, les bots devrons donc avoir 1 ip par place (ce qui coutera très cher et en découragera beaucoup).
Dans l'attente de votre réponse pour savoir si cela pourrais être déployé.
The text was updated successfully, but these errors were encountered: