Donations
|
If you wish to make a donation you can by clicking the image below.
|
|
|
|
31st October, 2001, 01:11 AM
|
|
damn this place ownz..... FIRST post !!! GRAHH!!!
anyways, on to his other mods.....
how would u guys like to have the user/pass login for servers ( not jsut a pass, therefor letting u know who is loging on if u got a passworded server... so pass's dont spred ) system done?
i need to know cuz i will be codeing the backend of the database, with a web interface for the server admins.... here is what i was thinking...
2 versions of my front end stuff, db's will still be the same:
personal server: ummm, u get your own database.. i give u an install script, and poof, u got a small website that ppl can go register for a user/pass word to your server.... auto given, or if u choose moderated ( they signup... but not an active account till the server admins says "GO!" )
ps: your own database does not mean we provide it... we jsut tell u know to set it up
central servers: well, here was my thought.... i'd host the db for this 1 off 1 of my friends networks, here is how i would set it up. server admins register there servers, u can then join a group or create 1 ( group like a web ring.... all a guys user/pass is good on every server within 1 ring, once 1 of the admins lets him in ), normal users sign up, then they can search throught the "web rings" to see what they wish to apply for....... idea's pls?
|
31st October, 2001, 01:39 AM
|
|
There is 1 discussion i'd like to go on in this thread (or another one), its in regards to security.
Basicly, you'd have to register your server(s) with the validation service for it to tell you if a player is valid or not, if your server is not registered, you get no info from the server.
Other things, i will need help with:
- How to prevent someone from registering 30 user names.
- How to catch players giving thier name/pass to others
and more
|
31st October, 2001, 02:52 AM
|
|
well, when some 1 attemps a login to a server, can it store soemthing in there ini?
if so, we can talk about that...
also, with reguards to the 30 accounts, i can do that all webside, varify's, ip checks, cookies or old server side sessions, whateva i deem needed to make sure we dont get flooded
with reguard to the first part of your post....does that mean that u HAVE to be registered on the cental server?.... thinking about it.. we cna host it there for everyone, and jsut let servers go without "rings".... they can be lone "rings"
|
31st October, 2001, 04:02 AM
|
|
What i would like is for security experts to jump in and help us figure the best way to handle this. or Submit suggestions and we will analyze them, discussing the pro/cons of each possibilily ..etc
|
31st October, 2001, 09:10 PM
|
|
Quote:
Other things, i will need help with:
- How to prevent someone from registering 30 user names.
- How to catch players giving thier name/pass to others
and more
|
I'm assuming that the login table stores the login name/PW. I suppose you could have a separate table store known IP addresses for a user (though this would give you a bigger performance hit at authentication time).
Anyway, storing user name/IP pairs gives you the ability to parse that data and look for suspicious info. One name that is connected to a large # of IP addresses (esp if they are from multiple domains) is probably indicative of one user sharing his/her login/PW info. One IP address (or range) that is associated with a large number of user names is indicative of a user going nuts with the registration system
This is pretty obvious stuff, but it's the first thing that came to mind.
Oh, and I think that having a central authentication server is the right way to go.
|
2nd November, 2001, 03:29 PM
|
|
Is there any combination of info in UT that could make someone uniquely identifiable, maybe with the combination of system information (like processor, or other system info that programs have access to)?
You could use that to generate a key, and store it in an .ini or something. (I don't know what powers you have from within UT for storing info)
If any of their info changes, just make the player re-register. If they play from multiple computers make them register from each of them.
I don't think IP's are the way to go because of dynamic addressing, but you could have an option when someone registers and they have a static IP and want to use it as part of their authentication they can. But that could get messy if people don't know what they are doing.
You could use a kerberos-type setup where the central server is a ticket authority and the ticket gives a player permission to play at one server or a "ring" of servers and if he wants to play at another server (or ring) he has to re-authenticate.
I may be taking it a little too far, but I'm not sure of the powers of uscript. just some thoughts.
|
10th November, 2001, 06:43 PM
|
|
heh
seems like this idea is pretty wide spread
My mod of this idea was supposed to be released to my community over a month ago.. .Darkbyte pretty much helped me construct half of the mod and later built his own version (tho with an implementation not like mine ) .. i never did launch it (the bastards in my community are not worth it... they pissed the hell out of me and i decided they can remain the lame alias using they are now :-P )
My approach to dealing with people trying to get more than one nick was simple... you sign with your email... Only true ISP emails are being accepted (no yahoo or hotmail or any kind of free account) .. being that i pretty much know everyone in this community and all the ISP's .. its easy to controll who's in and who's not :-)
maybe you should try the same for yours...
I never did create the tool that handles the DB tho.. damn :-)
|
25th November, 2001, 02:16 PM
|
|
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 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...
|
13th December, 2001, 04:48 AM
|
|
Is this project dead now?
|
13th December, 2001, 12:34 PM
|
|
No, its not dead .. but i had to give the priority to UTPure
|
23rd December, 2001, 12:38 PM
|
|
Zenkai hosts a public "Elite" server located in Texas. The name of this server is:
[Z]wineØnline[Z]
IP: 207.45.114.35:7777
We also have support from Clan SNOW who host a server called:
[Z]wineØnline[Z] #2
IP: 208.22.185.116:7777
Now we have allways wanted to make our server ([Z]wineØnline[Z]) a private server with password protection. However, in the past servers like this allways had the password leak out to anyone and everyone. Therefore a password just seemed to be more work for us admins and trying to keep it semi private was hard.
We would love a system like this. This system would require them to have a username/password to join our server. The problems I see are:
- someone taking another person's username and registering it
- sharing username/password
We would like to be the only ones who give authority to play on this server and the ability to delete an account (revoke privilages on this server). Maybe a "suspension" feature would be a great idea. Where instead of deleting an account I could suspend a user's account and have the option to choose a time frame (in number of days) that the user is to be suspended and after that time passes the user is automatically re-instated and given access to the server once again. Admin over-ride of suspensions would also be needed as if we feel the suspension was unjust or feel they have learned their lesson we should be able to un-suspend someone.
Another feature is an expansion to SemiAdmin to allow them to suspend someone from this server using the above example. As I have appointed some people who play frequently on our server to be a sort of "police force" and help keep the server llama free. I would like to give them the ability to suspend players from the server thru the console using the player's ID (not name as names can contain ASCII and that makes it very hard)
A web based registration sounds like a great idea as well. I look forward to reading more about this in the future.
Something else to think about :
Design some kind of ANTI-ALIASING feature that if the server admin wishes can implement. Thus stopping people from aliasing all the time and forcing them to play with their clan name or at least the 1 name they registered under. I am not sure if we would want to take away aliasing ability from our server but I would like the option to do so as aliasing has gotten out of hand and when people alias they are 100 times more likely to be assholes (as we have seen on our server many times)
Thanks again.
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
|
|
Thread Tools |
|
Display Modes |
Linear Mode
|
Posting Rules
|
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is Off
|
|
|
|