A Suggestion

[shadypalm88]

This is something that I was going to implement on my own bot before I lost interest in it.  It's based on two ideas:

1. You don't have to use all capabilities of BNLS.
2. If your bot has the capability to log in an account without using BNLS, there's no reason for it to ever send login information to BNLS.

Basically, the only reason your bot would ever connect to BNLS would be if the user's hash files are missing or out of date, and then only to perform check revision and get the version byte.  All password hashing would be done locally.  When you get the version byte from BNLS, it should be written to your configuration.  (On a sidenote, I've seen some bots where you simply change the version byte in the main settings.  So if you change products, you'll have to comment-out or re-change the version byte.  Do it by product instead.)  The decision on whether or not to use BNLS could then be made automatically.

I suppose you could also use iago's RCRS for this, but for existing BNLS bots this would be easier to implement.  I don't know if there are any bots that do this, but it seemed like a good idea to me.

[MyndFyre]

I don't know if there are any bots that do this, but it seemed like a good idea to me.

The API that I have available as open-source will do this if you define the MS_2 precomp constant in the project settings.  I agree, it is a good idea. 

[edit]
Basically I have a few different settings that control how BNLS/RCRS is used.  It is as follows:

Code Select Expand


/// <summary>
/// Specifies whether or not revision checking should be performed locally.
/// </summary>
/// <remarks>
/// <para>If this is <b>true</b> and the <see cref="ProductPath">ProductPath</see> property is <b>null</b> (<b>Nothing</b> in Visual Basic),
/// a remote revision check will be performed using the default RCRS server, if available.</para>
/// <para>If CD key and passwords are hashed locally, but revision checking is not, JinxBot will attempt to use the Remote CheckRevision Server
/// before attempting to use the Battle.net Logon Server.</para>
/// </remarks>
bool CheckRevisionLocally { get; }
/// <summary>
/// Specifies whether or not CD keys should be hashed locally or via your selected hashing server.
/// </summary>
bool HashKeysLocally { get; }
/// <summary>
/// Specifies whether or not passwords should be hashed locally or via your selected hashing server.
/// </summary>
bool HashPasswordsLocally { get; }
/// <summary>
/// Specifies your product path for local file hashing and revision checking.
/// </summary>
string ProductPath { get; }


[Eric]

This is how BNLS was intended to be used...

[shadypalm88]

This is how BNLS was intended to be used...

For the most part, it's not how it is actually used.

[Spht]

1. You don't have to use all capabilities of BNLS.
2. If your bot has the capability to log in an account without using BNLS, there's no reason for it to ever send login information to BNLS.

Obviously... BNLS exists so the programmer doesn't have to waste time with such things and can focus on more important aspects such as channel moderation code.  If you can already do it locally, then don't use BNLS.

You can only use BNLS to get the version byte if you want to.  Or you could only use it to do the login.  Or just use it to do the version check.

EternalChat was the first live BNLS client.  The idea at the time was that it was the only working bot that could log on to Battle.net without requiring actual game files.  Since it was so convenient to do so, and EternalChat was merely a BNLS test client, I also used BNLS to do the login authetication.  After some complaints in regards to people getting their account stolen "because of EternalChat," I decided to implement the login authentication locally and only use BNLS for the version and CD-key check, since the password is sent to BNLS as-is and someone tracing your connection activity (trojan or such) could easily log it.  That was around April 2002 I did this.

I'm fairly sure EternalChat, WebBot, and SphtBotv3 all do the login authentication locally for legacy products.

[Zakath]

Note that implementing the local login procedure for War3 is much more difficult and time-consuming than implementing the version check.