Jump to content
Sign in to follow this  
CarlGustaffa

isAdmin

Recommended Posts

Hi

Basically what the topic says, is it possible to check if someone is logged into a multiplayer server (for "game master purposes") as admin without checking against known admin names?

I was hoping for a player == isAdmin check or something.

Is this possible somehow?

I want admin to recieve certain actions in order to "set up the game". Description.ext let us setup to valueParams, but that's not nearly enough.

Share this post


Link to post
Share on other sites

The only way I have ever been able to check for admin status is to compare the player vs. a list of admin names in an array which of course means updating the list whenever admins change.

But, as an alternative, what about creating a custom dialog that asks for an admin "authorization code" that you can give to all your admins and if entered correctly gives them the extra action options you want?

Edit:

Of course you also need to find a way of hiding/"encrypting" the correct code fairly well in the mission/script in order to prevent people from de-pbo'ing it and learning the code.

Share this post


Link to post
Share on other sites

This is a good idea.

Maybe one way to go about it in a nice way would be to make a server side addon that contains the 'elevation' scripts and admin list. You would only have to update this, and not your missions. Your missions would have to be modified once to code in the server addon handling of course.

This code wouldn't be transferred, the server would run it. Then the client map would check if it was authorized via pubvar.

Not exactly secure, but good enough for honest folks.

Share this post


Link to post
Share on other sites

To find an admin on the server type #userlist in the type box and it shows you.

Share this post


Link to post
Share on other sites

I'm writing something along this lines right now, and opted out of the password scheme, and went for the admin list option. The admin list is stored in an external text file, and so can be updated on the fly by anyone that has ftp access to the server.

The reason for not using a password in this case basically boils down to the fact that anyone in the know who looks at the scripts carefully can write something to grab that password within minutes, and there's really nothing that can be done about it. To compound this problem, the end user is likely to use the same password for admining the server and the admin addon. Meaning that should I have gone with this scheme, it would be easy for an ill-intentioned person in the know to grab your server's admin password and have the whole range of administration options.

The other solution isn't foolproof either though. One obvious way of spoofing it is to join the server using the name of a known admin. If the server is running unsigned addons, you could also modify the client-side interface to always grant you admin status regardless of name. The damage caused by these methods is contained however, as it only gives the errent player access to the admin functions of the addon, but not the built in server commands, ftp access, etc. An alert admin should be able to catch these cases quickly, and give them the ol' kick-ban.

Share this post


Link to post
Share on other sites

About the password-idea:

I can see why you go for name, but I would go for both.

Unsigned servers will basicly always be a problem, so i'll not even comment on that wink_o.gif

You can always save the password only on the serverside.

Then by using setVehicleInit you can send and receive from the server, and verifiy if the password matches that what is known on the server.

Instead of setVehicleInit, you could use publicVariableEventHandlers, which would IMO be preferred over setVehicleInit (technically).

However, the problem with pvEH is that someone can fetch the password by monitoring the variable. One could solve this by letting the server generate a random variable at each mission start.. But I guess, on a signed server, this will never form a real problem anyway...

Share this post


Link to post
Share on other sites

Perhaps get the data from a config that is an "admin" addon on the server, and the script just checks that for the list. smile_o.gif

Share this post


Link to post
Share on other sites
Quote[/b] ]I was hoping for a player == isAdmin check or something.

There might be a way to detect who the Admin is. Can't say for sure, until I test out the method on this, specific task. I will get back to you after some testing, if your still interested?

BTW Are you that bothered about security and restricting these options to approved admins? Or do you just want the current admin to be the only one who can decide the mission parameters?

Share this post


Link to post
Share on other sites

For my needs, it's approved admins only UNN, not sure about his. Of course, my server admin rights are passworded, so only approved admins have the pass. Still, I want my stuff to be multi-admin friendly, so you can have 3 different admins doing things if you wanted.

Sickboy:

There's some troubles with a few of the things you're talking about.

Firstly, in a multi-admin environment (which is what I'm setting up), each admin would have to have a unique variable. The randomisation would solve that. However, determining the randomisedVariable name on the recieving end might be a tad problematic. You could work around these things, and I'm not saying you can't, it would be a little dicey though, figuring out what came from who.

On the subject of sending passwords over the network, they can always be sniffed, no matter what. The only protection you have is encryption, which doesn't really apply here.

Anyways, in a strictly signed server, both methods are actually pretty valid, depending on your needs, and combining them would honestly probably just be redundant. And as you say, unsigned can always be broken easilly.

Something interesting you *could* make use of maybe, but I've never tried it is this command:

http://community.bistudio.com/wiki/onPlayerConnected

It's supposed to return the playerID, the problem is that if multiple connected handlers are launched, only the last one is run by the game. At least that's what I read.

Share this post


Link to post
Share on other sites

I've posted an example function here, that returns true if a player is logged in as admin at mission startup.

Quote[/b] ]Of course, my server admin rights are passworded, so only approved admins have the pass.  Still, I want my stuff to be multi-admin friendly, so you can have 3 different admins doing things if you wanted.

If your using password security, why not have all the admin dialogs, scripts and functions in a separate pbo? A copy sits on the server and only the approved Admins get the pbo. That way anyone trying to hack the system won't even know what scripts and dialogs the Admins have access to.

Ok so you might have to use different pbo's for different missions, but won't that allow you to avoid all the hassle of each admin having to have a unique, randomised variable? All you would need is the player ID, which can be obtained in a variety of ways...see the thread I linked to above for one option.

Anyway, just a thought.

Share this post


Link to post
Share on other sites

According to this:

http://community.bistudio.com/wiki/isAdmin_%28VBS2%29

Isadmin is only VBS2. Has that changed?

Try having a client use server-side dialog classes. You can't, at least to the best of my knowledge. In fact, you can't use *any* class you don't have defined on your end. Note that classes defined in a mission's description.ext are sent to each player on connection.

This assumes a public release of a server administration tool which is mission independent anyways. Yeah, in the case of a private release, there's no threat on breaking the security of pbo really anyways. Any handy method will work.

Personally, my goals are thus:

Public release of a server admin tool addon, for the benefit of any server admin who wants to use it, which does this:

Allows the server admin to restrict aircraft to registered pilots, and further, allows some aircraft to be exceptions, which anyone can operate. Parachute base is a solid example of an exception, but camel, and mh6 might also be common.

Works on *ALL* missions, without the need to edit any mission.pbo files.

The admins, registered pilots, and aircraft are in a server side text file, and can be updated on demand (without need to restart the server or even interrupt the current mission between updates), by anyone with ftp access.

The tool comes with a nice dialog (client-side addon) that allows the server admins to alter who can fly what on the fly (pun intended).

Further, the core is separated from the pilot restriction section, so that modules can be added at will with ease, even potentially by other addon makers or gogetter server admins.

Anyways, I've actually achieved all of these goals, and the addon is being beta tested now. There's a couple of small bug's that we've found, which are to be fixed, but it's working just fine overall. I'm just interested in healthy debate of the best method of defining who is the server admin.

There are many tools I'd like to implement besides just the pilot restriction. This ranges from weapons limitations to even something similar in concept to the real time editor maybe. Other interesting thoughts include things like forcing respawn options (if possible), administrated fire support available in any mission the admin wishes to use it in, modifying the available starting gear for all players in any mission, possibly tools to aid in catching a hacker at work or even making a script you like work for all players in every mission, such as a script to airflift vehicles using a helicopter.

My basic method works like this:

On the server, there is a text file with a list of who is allowed to access the advanced admin functions which is loaded via the use of call compile loadFile in the server-side addon.

The server then sends this list to all players.

The clientside addon checks if the player is in this list, and grants admin access if he is, otherwise it shuts down. It also has the dialog elements, and code to manipulate them built in. It is responsible for requesting a current pilot list from the server side addon, and sending updates as required to the server. The clientside addon is not necessary for players to have, and someone that has it but not admin access to the server is ignored.

Again, I say that other architectures will work better for different needs, however, this one suits my needs intrinsically.

Anyways, sorry if I rambled, and probably didn't really come to a point. I'm just excited about releasing this soon, and even more excited at the thought of adding a whole bunch of cool shit to it.

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
Sign in to follow this  

×