View Single Post
  #8  
Unread 25th November, 2001, 02:16 PM
goemon
 
Posts: n/a
Default

IMHO the user/pass mod should do nothing more than:

1) Connect to an admin-specified ip/port and send the user,pass,and ip address, each on a separate line separated by CRLF.
2) Wait for a response code, either ACCEPT or DENY. DENY can be followed by a textual response message, which is displayed on the client's screen. Eg 'DENY Go to http://www.bla/ to sign up' or 'DENY Banned for cheating. Contact [email address] to beg for forgiveness'.

Whatever backend the admin wants to setup is up to them. They can even set it up to cascade to other servers if they want to, before giving the response code back to the mod.

It could do stuff like regexp for known clan names and cascade specific usernames eg [ClanName]* to ClanName's password server. This would actually be very easy to do.

By making the mod do as little as possible, we leave it up to the password server script/program to do all the hard work, and it can be very flexible. Different approaches can then be taken regarding server database replication/cascading, user signup pages, etc.

As for policies regarding signup flooding etc, that should be left up to the admin running the signup server to decide. Most admins would probably only accept signups from real email accounts, and throw away applications coming from hotmail/yahoo/anonymizers etc.

I'm a linux programmer and i've done tons of client/server stuff so I could write a portable unix backend for the mod.

I might be able to help advise the UT mod frontend design too, though I have very little knowledge what sort of capabilities UTscript has...
Reply With Quote