I agree that we should be able to configure a very short time limit for the menu system. It might also be a good to have an option to limit how many times, and how often a user can view who's online.

I also think there should be an option to consider a user inactive if they aren't expending any turns in-game. This would prevent silent keep-alive, and wouldn't allow a player to sit in the game all day long.

Good luck trying to limit the activity of someone that hasn't logged in...

As for expending turns, ok. So I setup a script to holoscan once an hour. Thus I'm expending turns. Easy workaround.

But they have logged onto the server, they just haven't entered a game yet.

The relog penalty does not take effect untl they log into the game. I'm just wondering if it's possible to put a limit on the amount of times a player can log onto the server per hour, then give them a limit of time sitting idle at the menu before they get booted off and are forced to reconnect again? Then limit multiple relogs.

OR - a server side TWX script to boot idle players? I may just have to learn how to code TWX afterall.

No they haven't. All they've done is entered in a BBS name, ie: a user name. They've provided no authentication at all. If you're going to start penalizing ppl based on their BBS name, I'm going to have a LOT of fun logging in as other people to get them time penalized.

Yes you can penalize people when they log into the game itself, but that doesn't affect their ability to sit at the game prompt menu. I can just as easily log in as another user as I can myself. You do realize you don't have to log into the game to sit at the menu, right?



Yea, you can do that. But they are capable of relogging, you know.

Yeah, I know, and they can log onto the server as anyone and sit at the menu and data mine.

We almost do need some sort of a bbs front-end to authenticate users logging in.

I'm going to see if summer classes have started yet, see if I can't get started on a computer science degree.

Well you can do a BBS, but that's not very secure.

What we need is a TLS option along with telnet/rsh. Have a public cert store and only accept matching certs. The sysop can then either accept X509 certs from people directly, or setup a front end w/ a cert and use that to auth ppl w/ a login and password. That same front end could be used to monitor and disconnect squatters, and it wouldn't have to be kept up by JP.



LOL yeh, have fun. Enjoy differential equations, I know I did.

Do any helpers support that?

You could track users by IP address, but that wouldn't prevent them from using proxy servers.

IP addy is useless. That's why we could use TLS authentication within TWGS. That would allow us to either secure connections directly, or create a truly secure front-end interface.

Currently, no helper supports it. But that's okay, you don't need helper support. There's always stunnel.

http://www.stunnel.org/

For those people that want to implement this concept w/o JP or TWGS support, you can do so. Using stunnel and a firewall, you can setup stunnel to accept inbound SSL/TLS connections and firewall the TWGS port. Nobody could connect in w/o going thru the TLS process.

Edit: Stunnel, being based on openSSL, supports OCSP. That means you could, theoretically, do all of this yourself. Setup stunnel, setup an OCSP server, firewall the main TWGS port. At that point, only those individuals in your OCSP server's cert cache could login, everyone else would be rejected. This would be one way of creating a secure login, as the sysop would know (logs) who was in the game at any point regardless of what name they use in TWGS. If you really want to eliminate camping, or enforce server rules, this would be one way to do it.

Problem is, the average Joe wouldn't be able to do this.



Who would be generating the certs?

Well, could put together a tutorial for it. Otherwise, there's nothing I can do. I don't have access to the TWGS code base. This is not a particularly difficult thing to set up.



X509 are certs are public/private key. You generate a public and private key. You keep the private key, give out the public key. The public key of the server would be given to people logging in so they can verify the server's authenticity. The public keys of the users would be added to the public key store of the server, and verified when people log in.

Each person would generate their own cert, this also fulfills the uniqueness requirement. Security is established by the transmission channel. A sysop would contact their user, via whatever method they deemed secure (phone call, email address, in person, whatever), and exchange public keys. As long as the user knows to keep their private key secure, the channel is secure. Should the keys become compromised, the sysop revokes access using the OCSP responder.

I would imaging the most secure way to do this for a TWGS server would be to get the user's name and phone number and talk that way. If you've talked with all of your users on the phone and gotten their information, it would be much more challenging to dupe.

I'm going to repeat this, because I think the point was lost.

Small node counts are meant for private or personal games. Public games need more nodes. With more nodes, this isn't really an issue.

With the next version, you'll be able to max out the server again for $100 or less depending on the slots and nodes you have. So it'll be reasonable to run a large site again. Not $350 like with the current pricing. I went with $100 rather than $80 because I do want to discourage larger sites more. We have too many large sites relative to the player base.

If this is an issue and needs addressing, I will do it. I don't share Vid's concerns about releasing new versions. I expect people to upgrade. There have been times when I released a new version every few days for months. Once a new version is out, it replaces the old ones. If someone's still running an older version, remind them there's a new one. There's always a reason for the new release. I don't do this just for chuckles.

BTW, Vid, I just fixed the empty ship records bug. New update is coming today or tomorrow. It won't be the last.

That was the original discussion, but the issue has changed from node count to eliminating menu squatters. This is an entirely different problem, and there's never been a good solution to it. It's part of a wider problem: there's no way to really know who your users are. That limits a sysop's ability to regulate his/her server.

Right. I could certainly put in a time limit along with the inactivity timer. Maybe based on time at menu so you can't just login to the game and back out to reset your time. You shouldn't be spending time at the menu. And if TW's time limit doesn't include sitting at the entry menu, that should probably change as well.

Don't waste your time with that. It's a 10 minute change to my menu watching scripts. I can just log in as another user, then log out and log back in as a normal user. There's no reason at all why the menu watching user has to be connected in any way to the non-menu watching user. You can even use proxies, if you want, to selectively mask your IP address.