I cut in the code I've been working on with my laptop recently.
Refactored auth code (new persistence package; r/m'd the old mysql.java) and added persistent ignore (which amazingly worked on the first try :).
Next I need to add a couple methods to IAuthenticator. isValidUser first off, so ignore can reject invalid users. Then some kind of channel op priviledges -- we have an accesslevel of Moderator, but it's completely unused.
It's worth pointing out that I'm using 1.4-only code in a couple places (just trivial re-throwing of exceptions). I tried leaving them out so people could keep using 1.3, but the 1.3 jdk was segfaulting on my linux box so I figured Screw it, we want 1.4 eventually anyway for the non-blocking sockets.
Maarten van Hoof
The countStatement in JdbcAuthenticator was not redundant: it disrciminates between users that do not exists and user that do exist but type an incorrect password. In your code, if both allowGuests and storeGuests are set, a person logging in with an incorrect password is added to the database under the incorrect password and given user levell access.
I've put the countStatement back from my local copy, and the comments too. Other than that your changes look good.
Regarding Java 1.4: thats fine with me I don't see why we would want to keep using an ancient Java version. You should, however, change the comments in the run script that say you need jdk 1.2.2 or higher. And you should make sure not to use 1.4 on the client side, of course.
In your setup, what has the IAuthenticator to do with ignore? Isn't ignore just a list of users that you retrieve when a user logs on, use to fill the ignored list with and then store when the user logs of?
Did you see my sugestion for using the version command to discriminate between your client and the original clients?
How's your client comming along?
IAuthenticator -- IMO this is the logical place to add a isValidUser(String username) so /ignore can reject invalid users. in fact the Count stmt would be good for this (which should be called AFTER password check fails -- optimizing for most common case).
saw your suggestion on /version. will use it, when I get that far.
client is coming OK; I will move carnageblender to NFC + my client (from current IRC chat) as soon as I also add something to configure which users can create/moderate channels. that's when it'll get real testing. :0 (it would be nice if non-blocking IO + less threads went in too but my current user load doesn't demand it.)
BTW, I haven't noticed anything in NFC for throttling -- restricting how often users can send messages/commands. I'd like to have a look at adding this too.
What you mean is you want to check whether the ignored user actually exists when somebody sends an ignore request? Why not just assume that only users logged at that point in can be ignored?
I agree that IAuthenticator would be the proper place to put such a check.
Go and move the count statement if you want to change the class again :)
There's nothing for throttling that I am aware of.
shrug, you could only ignore logged-in users but since it's almost free to do it "right," why not? :)
possibly NullAuthenticator could check currently logged in users for this call but we'd need to give IAuthenticator a reference to the current server object. Which isn't necessarily a bad thing...
Maarten van Hoof
As you said yesterday: optimize for best performance. Check the server state first, then the database.
Give IAuthenticator all references he needs ;)