This is my Doorman idea.
You are running a network of hubs. You want to get rid of search bots, spiders and other nasty users.
You set up a simple hub that has no search, no userlist, nothing except user authentication.
This hub also is a bot in the hubs that it acts as a doorman for. These hubs will only allow users in from authenticated IPs. For an IP to be authenticated the Doorman bot has to tell the Hub. These hubs will be set up to ignore any packet not from an authenticated IP. This way anybody who hasn't gone through the Doorman hub first can't get in. The user would still need to log in to the hub.
The Doorman could be used to distribute users across the different hubs. Or used to sync main chats. Or could be used to create a Private hub and a DMZ hub.
An idea for hub security against bots
Moderator: Moderators
-
ButterflySoul
- Posts: 210
- Joined: 2003-01-23 22:24
- Location: Nevada
The only problem with gateway / portal hubs is that many clients don't automatically follow redirects; so the whole process can't be automated.
There are already many portal hubs running. Usualy a few OPs check your share, your client, then create you an account on the main hub and give you the right address for it (the main hub typically being "registered users only", so it's already protected against search bots and other crawlers =)
Your doorman idea requires some serious scripting (if you want to feed the "authenticated IPs" in realtime to the other hubs) and a "backwards ban" at the hub level (right now, you can make a hub refuse all packets from an IP if it's banned, but you can't make it accept packets "only if it's listed").
It would only be better than the current system if you somehow manage to fully automate it and :
1) Automatically determine if a client is a harmful bot/crawler
2) Somehow manage to solve the "clients not automatically following redirects" issue. Heck, in JDC, it's not even a feature of the client in the options, but directly how the client works. It plain ignores the protocol data if it's a $redirect command (according to David Marwood's protocol reference anyway)
At this point, it merely seems like a more complicated way to archieve the same result, but maybe I missed something. Feel free to elaborate =)
There are already many portal hubs running. Usualy a few OPs check your share, your client, then create you an account on the main hub and give you the right address for it (the main hub typically being "registered users only", so it's already protected against search bots and other crawlers =)
Your doorman idea requires some serious scripting (if you want to feed the "authenticated IPs" in realtime to the other hubs) and a "backwards ban" at the hub level (right now, you can make a hub refuse all packets from an IP if it's banned, but you can't make it accept packets "only if it's listed").
It would only be better than the current system if you somehow manage to fully automate it and :
1) Automatically determine if a client is a harmful bot/crawler
2) Somehow manage to solve the "clients not automatically following redirects" issue. Heck, in JDC, it's not even a feature of the client in the options, but directly how the client works. It plain ignores the protocol data if it's a $redirect command (according to David Marwood's protocol reference anyway)
At this point, it merely seems like a more complicated way to archieve the same result, but maybe I missed something. Feel free to elaborate =)
Who is online
Users browsing this forum: Google [Bot] and 0 guests