Page 1 of 1

Multiple problems in a dead-simple plugin ...

Posted: Fri Feb 10, 2012 11:38 am
by Beardy
As my first plugin I'm trying to create something which will automatically make anyone who logs in from the local machine (IP equals 127.0.0.1) an operator.

In the below case I logon locally as an observer (client#1), and than also logon locally as a second observer with 4 robot-tanks (client#2).

The first problem:
When I execute the 'SetPlayerOperator" call the shown sign-on message of the observer (client #2) in the other observers client (client #1) is different. Instead of "observer2 joining as an observer" I get "observer200 joining as a robot tank". Followed by sign-on messages for all robot tanks (including one with the "observer200" name).

Mind you, this is a difference observed by calling/not calling the above function in an otherwise un-altered plugin.

The second problem:
The admin-marker ("@") infront of the playername does not appear until after someone else joins (player or robot).

The third problem:
When I use the "/flag give <player> <flag>" command (from either client) it get unexpected results. Although I get a message from the server that the flag has been given and a flag appears ontop of the targetted tank it seems to pretty-much ignore it. CL seems to work, but a weapons-change to SW, MG or GM does not. giving SW causes the robot-tank to stop shooting altogether (the server shows messages that the shots are faulty, and therefore cancels them).

Has anyone an idea what is going on here ?

Re: Multiple problems in a dead-simple plugin ...

Posted: Fri Feb 10, 2012 6:10 pm
by JeffM
1) Solo bots are different so they do log-in differently then normal clients. They are attached to a real player connection, so I believe your observer will log in first then it will just ask for some bot slots and add them. I would need to see your specific code to fully understand the issue. Does the same issue happen with real players? or just with solo bots?

2) The admin marker is sent with the initial player data when they are added to the game. It is based on permissions granted when the user authenticates with global login. Calling /password or set operator after that will not resend the player data (there is no facility to update this in the current protocol IIRC). Basically your API call is too late. The only place the API can change that symbol is by setting the bits in the bz_eGetPlayerInfoEvent/bz_GetPlayerInfoEventData_V1 event/data.

3) Solo bots don't have the same client logic as real players. They do not know how to use shot flags. The shot type is sent out by the client so they do not generate the correct shot types. CL and other "effect" flags are handled by the remote player so they work (your client sees that the bot has CL and dosn't show it ). Solo bots are REALLY limited in what they can do and should not be treated as regular players. The autopilot system does work better since it hijacks control over an existing real client, but you can only have a single autopilot per client.

Hope that helps. Please feel free to log into IRC to discuss if you would like, we are glad to help.

Re: Multiple problems in a dead-simple plugin ...

Posted: Sat Feb 11, 2012 1:19 am
by Beardy
JeffM wrote:1) Solo bots are different so they do log-in differently then normal clients. They are attached to a real player connection, so I believe your observer will log in first then it will just ask for some bot slots and add them.
True. And there is the problem: when I connect with as a human observer which also wants to introduce a robot the log-on message for the human disappears and is replaced by one of a a robot logging on.
JeffM wrote:I would need to see your specific code to fully understand the issue.
bz_ePlayerJoinEvent and SetPlayerOperator executed in there. There is nothing else to it.

And you can have the code, but you would probably not understand. I'm the kid who uses Windows without using VC, remember ?
JeffM wrote:Does the same issue happen with real players? or just with solo bots?
It happens with an Observer, but not with a player. When I connect with client #2 with a human player and bots the human player log-on on client #1 is mentioned twice: first normal and than again with mentioning its IP (and after that the robots).
JeffM wrote:2) The admin marker is sent with the initial player data when they are added to the game. It is based on permissions granted when the user authenticates with global login. ... Basically your API call is too late.
<huh> As far as I can see there is no earlier event for this kind of checking.

But if that is so its odd: as far as I can tell the PlayerJoinEvent is send well before the GetPlayerInfoEvent. So Why does that last one not reflect the changes made in the first one ?
JeffM wrote:Calling /password or set operator after that will not resend the player data (there is no facility to update this in the current protocol IIRC)
Is there an API function-call with which I can force a resend ?
JeffM wrote:The only place the API can change that symbol is by setting the bits in the bz_eGetPlayerInfoEvent/bz_GetPlayerInfoEventData_V1 event/data.
I don't understand: If the GetPlayerInfoEventData does not reflect the actual status set (by the SetPlayerOperator function), then where am I supposed to get it from ?
JeffM wrote:3) Solo bots don't have the same client logic as real players. They do not know how to use shot flags. The shot type is sent out by the client so they do not generate the correct shot types. CL and other "effect" flags are handled by the remote player so they work (your client sees that the bot has CL and dosn't show it ). Solo bots are REALLY limited in what they can do and should not be treated as regular players.
Yes, that was what I deduced from what was happening. But as I could not find any reason why a robot-tank would accept a flag (and/or not directly throw it away) but not use the already available code for the player to show (not use) the shot-type as it was set I doubted my conclusion. Thanks for confirming it.
Hope that helps. Please feel free to log into IRC to discuss if you would like, we are glad to help.
Thanks for the offer. Alas, I do not have any such chat-method available (tried it, it didn't work out), so I'm afraid I'm limited to communication using this forum.

Re: Multiple problems in a dead-simple plugin ...

Posted: Sat Feb 11, 2012 6:44 am
by JeffM
wow, quotetastic. Lets see if I can make a clear response.

There is no way to force a resend of the player data as I said, the networking system doesn't allow it. All you can do is set the bits in the GetPlayerInfoEventData, and no it does not actually reflect the settings, it's JUST used for what mark they get when those flags are sent to the remote clients. The event was intended to let admins be "hidden" if desired.

The permissions to do an action or not are controlled by named permissions the player has. This is done on a per action basis. You can use the hasPerm, grantPerm, and revokePerm methods to mange them.

"Operator" is a special status that doesn't actually grant any named permissions but is used to override any check to see if a user can do an action. This is why it does not affect the @ system at all. By default @ is granted to users that have a ban permission at authentication time. Your calls to set operator are just too late. The operator function is being phased out and replaced with the permission system. It will work with fewer and fewer things in the future. The main reason for this is to remove the plain-text transmission of passwords over the networking system. This is why local identify was removed.

As for your issues with solo bots I don't know what else to say. They are weird and that's just how they work. BZFlag was not written by someone who knew a lot about modern software or networked simulations. As soon as we have stable server side bots we will probably remove solo bots due to the huge amount of problems they have.

Re: Multiple problems in a dead-simple plugin ...

Posted: Sat Feb 11, 2012 12:07 pm
by Beardy
JeffM wrote:wow, quotetastic. Lets see if I can make a clear response.
:-) Just so you or anyone else does not need to think about "what did I say that he says this".
JeffM wrote:There is no way to force a resend of the player data as I said, the networking system doesn't allow it.
I already thought so, but had to ask to make sure.
JeffM wrote:All you can do is set the bits in the GetPlayerInfoEventData, and no it does not actually reflect the settings, it's JUST used for what mark they get when those flags are sent to the remote clients. The event was intended to let admins be "hidden" if desired.
I'm sorry, but I was not altering any bits/flags in that datastructure. I was just wondering why that datastructure does not directly reflect the operator-flag set in a previous event.
JeffM wrote:This is why it does not affect the @ system at all.
My apologies, but it does.

If I make everyone an operator (in the bz_ePlayerJoinEvent event) and log-on with a few robots only the last added robot does not show that "@" marker, all robots and the human before it do. In other words: there seems to be some kind of "delay" involved.
JeffM wrote:The main reason for this is to remove the plain-text transmission of passwords over the networking system. This is why local identify was removed.
But you didn't. I've already mentioned to 'blast' that you guys actually send the callsign and password in plain-text in the http-request to the list-server. Anyone between the player and the list-server can grab and abuse them for a game. Worse, they are also used for this forum ...

Alas, when I mentioned this to 'blast' he did choose to either play dumb and/or simply flatout lie to me by saying there was no such problem. Why ? I don't know.
JeffM wrote:As for your issues with solo bots I don't know what else to say. They are weird and that's just how they work.
Good enough for me. It was just that I did expect the robots to just use the same bullet-firing method/code as the human tank, and was wondering if I made a mistake somewhere. I didn't. :-)

Re: Multiple problems in a dead-simple plugin ...

Posted: Sat Feb 11, 2012 2:08 pm
by blast
Beardy wrote:
JeffM wrote:The main reason for this is to remove the plain-text transmission of passwords over the networking system. This is why local identify was removed.
But you didn't. I've already mentioned to 'blast' that you guys actually send the callsign and password in plain-text in the http-request to the list-server. Anyone between the player and the list-server can grab and abuse them for a game. Worse, they are also used for this forum ...

Alas, when I mentioned this to 'blast' he did choose to either play dumb and/or simply flatout lie to me by saying there was no such problem. Why ? I don't know.
I did not lie nor play dumb. You said that "BZFs" (lower case s is the key, apparently!) sends passwords in plain text, which I read as "BZFS", as in, the server. So I responded that it did NOT in fact do any such thing. It was pretty damn obvious that I misread, because I said "BZFS doesn't send any passwords via HTTP. A token is not a password." But if you want to start spreading lies about me, feel free to see how far that gets you.

Re: Multiple problems in a dead-simple plugin ...

Posted: Sat Feb 11, 2012 4:50 pm
by Beardy
blast wrote:It was pretty damn obvious that I misread,
You have "misread" so many things -- both in our PM exchange as well as in the "Where to apply for unbanning?" thread, where you accused me of suggesting stuff which, in fact, you yourself suggested -- that in that respect I can't trust you anymore.
blast wrote:But if you want to start spreading lies about me, feel free to see how far that gets you.
I don't need to lie.

The "Where to apply for unbanning?" thread is there for everyone to read, inclusive my getting angry at you for "misreading" and you blatantly igoring it like you ignored pretty-much everything else. If you want I can also post our PMs so that everybody here can judge for themselves. The sharp change in how you spoke to me in public and in private is pretty note-worthy, don't you agree ?

Re: Multiple problems in a dead-simple plugin ...

Posted: Sat Feb 11, 2012 5:18 pm
by JeffM
There is no need to turn this into an argument.

That's just the way the software works, if it's not good enough for your needs.. sorry.

Yes I was incorrect about the operator setting @ for subsequent joins, I missed a call to isOperator in isAdmin. The system is just not robust enough to handle setting it for existing players. That's just the way it is.

Yeah our security sucks, we are trying to make it better. Sending plain text to a web server that we control is better then sending plain text to a server that an unknown controls. It's a step in the right direction.

The API can not do all things, and many things are limited by the poor way bzflag is implemented. To fix that we have to pretty much rewrite the entire thing and throw out all the old code from 1994.

Re: Multiple problems in a dead-simple plugin ...

Posted: Sat Feb 11, 2012 7:24 pm
by Beardy
JeffM wrote:There is no need to turn this into an argument.
I'd rather not either. I already got a belly-full of it and it still makes me sick.
JeffM wrote:That's just the way the software works, if it's not good enough for your needs.. sorry.
You mean that thing with the plain-text password ? That was just the end of a bit of an exchange about a possibility to identifying a client directly with a game-server, not thru the list-server. His answer: Going thru the list-server was a lot better/more secure, cause the passwords could not get intercepted. I just pointed out that he was wrong in that regard.
JeffM wrote:Yes I was incorrect about the operator setting @ for subsequent joins, I missed a call to isOperator in isAdmin. The system is just not robust enough to handle setting it for existing players. That's just the way it is.
Not really a problem, I just wanted to make sure that I didn't miss anything myself.
JeffM wrote:Yeah our security sucks, we are trying to make it better. Sending plain text to a web server that we control is better then sending plain text to a server that an unknown controls.
True. But why than not simply stop sending the password in plain-text (to the game-server) ?

As I mentioned to 'blast', hashing the password together with the name of the game (and/or maybe the domain-name too) would make the result unique for that one game-server. To me that looks like a secure, and rather simple solution.

Ofcourse, a challenge-response system could also be used (think of how SAMBA uses cerberos).
JeffM wrote:It's a step in the right direction.
I do not fully agree with you, as the list/authentication-server than becomes a single-point-of-failure: If it fails to work (for whatever reason) there is no way a registered player can enter registered-only games (or admin such a game-server).
JeffM wrote:The API can not do all things, and many things are limited by the poor way bzflag is implemented. To fix that we have to pretty much rewrite the entire thing and throw out all the old code from 1994.
Well, there are several things that I think could get improved without too much effort.

Like combining the "you are not allowed to enter this server" (for whatever reason) flags, than execute the bz_eAllowPlayer event, and only than look at the result and actually kick the player (or not). That way a plugin could add a ban, but remove one too (would have been nice for my "don't apply IP-range bans to registered players" idea).

Like adding an bz_eUnBanEvent (to complement the bz_eBanEvent).

Like running the internal commands thru the bz_eSlashCommandEvent too, so they can get overridden.

But hey, you mentioned that you where already swamped in work, so I won't even try to suggest stuff like that anymore (But I just did. Devious me ... :-) ).

Re: Multiple problems in a dead-simple plugin ...

Posted: Sat Feb 11, 2012 7:41 pm
by JeffM
There are lots of things that can be improved, development is dying on bzflag so that likelyhood is slim. Nobody is swamped with work. Nobody cares much about development. 2.4.2 will probably be the last release.

yes there are LOTS of better ways to handle our security.

For the global list server, yes it can be intercepted, it is just harder for someone to actually pull it off when the password is not sent to the game server (global auth never sends a player password to the game server). I don't think anyone meant they could NOT be intercepted but meant that it narrows down the places where it could be.

Honestly I'd SSL the entire thing. The entire authentication system is a joke.

The entire network connection system is also a joke. I don't see there being any changes to it since most of the changes would require large rewrites to how the server does things and changes to the networking protocol.

Re: Multiple problems in a dead-simple plugin ...

Posted: Sat Feb 11, 2012 8:26 pm
by Beardy
JeffM wrote:There are lots of things that can be improved, development is dying on bzflag so that likelyhood is slim. Nobody is swamped with work. Nobody cares much about development. 2.4.2 will probably be the last release.
Hmm... Thats too bad.
JeffM wrote:yes there are LOTS of better ways to handle our security.
As easy as you can agree to that, as stubborn 'blast' was/is in denying it. :-\
JeffM wrote:For the global list server, yes it can be intercepted, it is just harder for someone to actually pull it off when the password is not sent to the game server (global auth never sends a player password to the game server).
Agreed.
JeffM wrote:I don't think anyone meant they could NOT be intercepted but meant that it narrows down the places where it could be.
I do not know about "anyone", but I know of a certain person who probably did not even think that far, and definitily did not mention anything in that regard.
JeffM wrote:Honestly I'd SSL the entire thing. The entire authentication system is a joke.
That would certainly shield the exchange for prying eyes. However, it would do nothing at al for the basic "the other side may not know my password" problem.
JeffM wrote:The entire network connection system is also a joke.
I'm not sure which part you mean. Sorry.
JeffM wrote:I don't see there being any changes to it since most of the changes would require large rewrites to how the server does things and changes to the networking protocol.
Well, even if large changes can't be made, small changes could probably still be done ? Giving server-owners (and plugin-builders) a bit more freedom in what they can do would probably not do any harm. More likely the opposite.

Re: Multiple problems in a dead-simple plugin ...

Posted: Sat Feb 11, 2012 9:34 pm
by JeffM
You can stop mentioning blast he has no bearing on this discussion.

Yes the people who did auth originally did not think very far. But blaming the past don't fix the future.

Even small changes seem hard to get done these days. 2.4.2 is only going to have a few fixes, it is mostly to get the Debian package out for 2.4.x.. only 7-8 months after release....

I would not expect any sizable changes to the API at any time, specially not any changes dealing with the order of events for client joining or permissions. The API functions are tied directly into how the server processes network traffic.

If you would like to discuss security and authentication ideas in games, I'm all for that, it's just a different subject then this thread and should be handled elsewhere. I have done a lot of research into it.

Re: Multiple problems in a dead-simple plugin ...

Posted: Sun Feb 12, 2012 10:08 am
by Beardy
JeffM wrote:You can stop mentioning blast he has no bearing on this discussion.
My apologies, but he affected me badly and some of the brought-forward points seem to call for it.
JeffM wrote:Yes the people who did auth originally did not think very far. But blaming the past don't fix the future.
??? I do not blame them at all. They have probably made the best decisions with the available information. As you mentioned, BZF was never intended for internet-play and some of the earlier decisions where affected by that. Including the authentication system. Which is why you changed it to use an authentication-server.
JeffM wrote:Even small changes seem hard to get done these days. 2.4.2 is only going to have a few fixes, it is mostly to get the Debian package out for 2.4.x.. only 7-8 months after release....
Somehow I got the idea that the development of 2.x was alive-and-kicking, it was just the ammount of players that did drop off a bit. But in that case I will try not to make more suggestions.
JeffM wrote:I would not expect any sizable changes to the API at any time, specially not any changes dealing with the order of events for client joining or permissions. The API functions are tied directly into how the server processes network traffic.
Hmmm too bad. I was looking if I could create an different authentication system in a plugin (for starters as a proof-of-concept), but it looks like the way the plugin-API is written its not really up to that. Bummer ...
JeffM wrote:If you would like to discuss security and authentication ideas in games, I'm all for that, it's just a different subject then this thread and should be handled elsewhere. I have done a lot of research into it.
Well, I'm not actually into security and all that. I got a bit carried-away in the discussion in regard to excluding registered players from ip-range bans and a following part of how to at least slow-down disruptive anonymous players. A simple authentication-system for those anonymous players could have helped there.

Re: Multiple problems in a dead-simple plugin ...

Posted: Sun Feb 12, 2012 4:57 pm
by JeffM
Yes, replacing authentication is a bit more then a "dead-simple" plugin. I do not think all the API hooks are there to do that.

Re: Multiple problems in a dead-simple plugin ...

Posted: Mon Feb 13, 2012 10:22 am
by Beardy
JeffM wrote:Yes, replacing authentication is a bit more then a "dead-simple" plugin.
Not replace it, but to add another method to it.
JeffM wrote:I do not think all the API hooks are there to do that.
Very true. As I mentioned, the three standard ban-methods are already applied before the API gets into the picture. It means that a plugin can only reject even more players, but not allow them in (overruling the standard bans).

Same goes for adding to ban-lists. When you add one its is applied without any API method to see who gets affected. The only thing you can do is to fully block the IP-ban method (can't do the same for the other two), and thats not really what I was after.

In short: I'm not sure what the idea behind the API was, but to me it looks that the ability to override standard behaviour was not part of it. And that makes it impossible to implement something like my "alternate authentication" idea. To bad, but its not to be helped.


By the way, I can't remember having heard much about the first problem i posted. After our conversation I can imagine its linked to the second problem (the missing "@"), but am not sure at all.

[edit]
I see I missed a bit in your post.. Yes, an authentication-plugin is not really what you would call "dead-simple". It looks we got a bit side-tracked by the authentication thingy ...

Bit its not that hard either though. Assuming that the password+site hash gets created at the client-side (for testing-purposes one could even be typed in) and send as, for example, the motto or pre/postfixed to the callsign (and in both ofcourse removed from there by the plugin) its nothing more than a simple comparision against a list (callsign + hashed password). Pretty-much the same as is currently done with single-IP bans.

Capturing and evaluating a couple of slash commands would enable an admin to add and remove hash-passwords to/from a list. Mind you, the admins would not even need to see the used hash, they would just need to be able to "point at" a user and tell the plugin to do whats needed.

Re: Multiple problems in a dead-simple plugin ...

Posted: Mon Feb 13, 2012 5:27 pm
by JeffM
The API was to allow simple modifications to the server logic for extension of the game. Take a look at the existing plugins and you can see what people have done (change spawns, move flags, etc..). Most of what it does is after a player joins, after authentication.

It was not designed to allow for complete new features to be built entirely in the API. It also can not change anything on the client.

Re: Multiple problems in a dead-simple plugin ...

Posted: Tue Feb 14, 2012 10:57 am
by Beardy
JeffM wrote:The API was to allow simple modifications to the server logic for extension of the game. Take a look at the existing plugins and you can see what people have done (change spawns, move flags, etc..).
Yes, I've seen the plugins provided to the game. Some nice game-play additions.
JeffM wrote:Most of what it does is after a player joins, after authentication.
True. But some of the other events did look promising. For example the events bz_eAllowPlayer, bz_eBanEvent as well as a few commands in regard to banlists.
JeffM wrote:It was not designed to allow for complete new features to be built entirely in the API.
every API has got some restrictions. Its just that when a restriction looks like a mistake (re-ordering a few commands would give a lot more possibilities/freedom) I cannot do other than to ask to the reason of it -- maybe it really was a mistake and the programmer (I assume it was you) was just not aware of it. My apologies if I offended anyone (you) with doing so though.
JeffM wrote:It also can not change anything on the client.
You mean in regard to the authentication ? Well yes, the client would need to get an update. But with the number of cheat-clients around I don't think that a small addition like creating a hash outof two strings and putting it into the logon-message would be too much of a problem.

The idea was that a game-server could simply add the plugin, no changes to the origional code needed. The player would than have the choice to play with the official client, or with a modified one which would allow them a bit more access.

Re: Multiple problems in a dead-simple plugin ...

Posted: Tue Feb 14, 2012 6:33 pm
by JeffM
A mistake would imply that the software is not working as intended or not to spec. BZFlag has no spec. The API was designed to simply provide access to some existing events that BZFS already did. Nothing was reordered in BZFS to accommodate the API. When making the API, replacing the authentication system was not one of my design goals. I would rather improve our global auth instead of adding more authentication systems. It's just not something I feel the project should do. A robust global system would be better then a large number of different local systems for a number of reasons.

The mistake I did make was adding /identify authentication back in 1.10, that mistake has been corrected when it was removed in 2.4.

The bz_eAllowPlayer, bz_eBanEvent are intended to allow for external/shared storage of ban lists via plugins. A function they perform just fine now.

If you are going to require a modded client to work with your plugin then I don't see how your deployment will work out for you. If a player has to know what client they are going to use before they join a specific server then I'm not sure how useable that is.

It sounds more like you want to make a fork.

I also do not understand why you are worried about not needing a mod to the server, when you are needing a mod to the client. Server mods are much simpler to deploy then client mods, and if you are programing in assembly like you have hinted in the past, I do not see how you are going to distribute these changes. If you have to mod the client, then go ahead and mod the server too. There will be a lot fewer server deployments that use your system then there will be players of it even in a best case.

Re: Multiple problems in a dead-simple plugin ...

Posted: Tue Feb 14, 2012 8:34 pm
by Beardy
JeffM wrote:Nothing was reordered in BZFS to accommodate the API.
I did not say or imply that. I said that re-ordering would "give a lot more possibilities/freedom".
JeffM wrote:A robust global system would be better then a large number of different local systems for a number of reasons.
As I said before, such a "robust global system" would also be a big problem when it would fail, for whatever reason, to function for any length of time.

And as I also mentioned before, I did not mean to replace that "robust global system" (for the standard registered players), just to add another option (for non-registered players). Which, by the nature of a plugin, would be fully upto the owner of the game-server to use it or not.
JeffM wrote:The mistake I did make was adding /identify authentication back in 1.10, that mistake has been corrected when it was removed in 2.4.
We seem to be on different tracks here. I do not know why you think it was a mistake, other than maybe that the method itself used at the time was simply not robust. Mind you, the whole world seems to handle the point-to-point authentication with passwords quite well, so I haven't got the foggiest why you seem to be thinking it would not with BZF.

But please don't respond to that. Its clear to me that you have no desire to think about anything else than "a robust global system", so any further exchange in this regard would probably be just a waste of both of our times.
JeffM wrote:If you are going to require a modded client to work with your plugin then I don't see how your deployment will work out for you.
Did already mention modified clients ? How do they get from the guy who makes them to the guy who uses them ? I think "my" deployment could work the same way. Ofcourse, another way would be to just package the modified client with the plugin.
JeffM wrote:It sounds more like you want to make a fork.
I have no intention to do that. I thought that the API could accomodate an experiment. It can't. End of story.
JeffM wrote:If you have to mod the client, then go ahead and mod the server too. There will be a lot fewer server deployments that use your system then there will be players of it even in a best case.
Is that what you are worrying about ? Loosing players to another fork ? Don't. I had nor have any such intention.

Lets end this conversation, shall we ? I think everything has been said.

Re: Multiple problems in a dead-simple plugin ...

Posted: Tue Feb 14, 2012 8:58 pm
by JeffM
Please feel free to ask about other API issues you encounter, it's always good to see what people are using the code for.