GM Tool Pangya Preview

[suneka]

Hello everyone ...

I am developing a tool to manipulate the server commands.

Preview




Very soon I will be posting this for everyone.

Features

1. Register and delete Global Messages

2. Send instant message or to schedule a date and time specified.

3. Rate of change from Scratch, Black Paper, Pang, XP simultaneously for each server and can be scheduled beginning and end.

4. Sending custom commands without needing to access the database.

5. List of Commands scheduled with the possibility of removal when necessary.

Language: PT-BR

It still has some minor bugs and has no way to configure other servers without being ours. Once finished I'll post it for everyone.

Powered by pangya.gmaniacos.com

[MentaL]

[TheLost]

Very Niceeeeeeeeeeee, thank you for post

[X_Sarah_X]

When creating a tool its important to include at least a setting to use ENGLISH as a language.
I will not use this, due to the fact it's in a language I can't understand for even a bit.

Looks nice though.

[suneka]

I go work for translation for english.
;)

[TheLost]

Several people on this forum understand Portuguese, I believe it is a very important tool

[X_Sarah_X]

You wouldn't like me to release my stuff in dutch either, would you?
English is a universal language, and should be the main language used when releasing tools to public if you ask me.

[top1]

You wouldn't like me to release my stuff in dutch either, would you?
English is a universal language, and should be the main language used when releasing tools to public if you ask me.

i think so

[baue]

nice!!!!!

[Tsukasa]

It's each and everyone's choice what language they release stuff in. If it's in Portuguese - fair enough. Nobody is forcing you to use it. Since it's obviously being developed for/on gmanicos it makes sense that the tool is in the primary language of their userbase.

But as I told some people before: Any tool that is designed for external use but requires you to have direct access to the database is a failed attempt and a security nightmare. Which makes me wonder... who's the target group for this program?

Any sane person would only use this on the same machine the server is running on or the same network - which rules out GMs. Lazy administrators probably find it easier to hack together a simple query they execute every x hours to manipulate the server values instead of having to use a tool and drill a click-routine.

Just saying...

*Edit: Before people start hitting me with clubs because I'm not full of praise... I'm talking about _desktop_ applications - browser-based stuff would be exempt from this and probably force people to authenticate against the application itself (i.e. checking whether a specified login name is GM and allow or deny access to the tool based on that)!

[chiosin2]

i would say great, can't wait. but i have to side with tsukasa on this one. i'd rather use my php scripts to use Stored Procs, err.. The tip also came from tsukasa.

[chreadie]

Im with tsukasa, because all the authmecanisms are already there. Reverseengineer the networkprotocol and we Will have à nice client.

On the language issue, make your own tool if others arent what u want.
Posted via Mobile Device

[suneka]

It's each and everyone's choice what language they release stuff in. If it's in Portuguese - fair enough. Nobody is forcing you to use it. Since it's obviously being developed for/on gmanicos it makes sense that the tool is in the primary language of their userbase.

But as I told some people before: Any tool that is designed for external use but requires you to have direct access to the database is a failed attempt and a security nightmare. Which makes me wonder... who's the target group for this program?

Any sane person would only use this on the same machine the server is running on or the same network - which rules out GMs. Lazy administrators probably find it easier to hack together a simple query they execute every x hours to manipulate the server values instead of having to use a tool and drill a click-routine.

Just saying...

*Edit: Before people start hitting me with clubs because I'm not full of praise... I'm talking about _desktop_ applications - browser-based stuff would be exempt from this and probably force people to authenticate against the application itself (i.e. checking whether a specified login name is GM and allow or deny access to the tool based on that)!

So it has not yet posted.

I'll make a settings page

where the person put their IP 127.0.0.1 Ex Login: SA Password: 123456 and a screen that alone will enable the command execution if it has a GM account indicated in the database with authentication.

[chreadie]

But a GM Account is not the same as a DB Account.

[Tsukasa]

If I have your database credentials, I don't need to be GM anymore (if you really give out your sa credentials).

That's the entire point of our critique here. As a service provider you never ever give people direct access to your database. If I were GM on your server, got your tool plus your database credentials and had a bad day, I could mess up stuff big time if the database administrator didn't set up the permissions properly (and let me say one thing: I doubt most of you people here have a sophisticated database setup, so this is a real issue). So let's say I fubar'd your database and you finally cast me away from my position as GM. Are you going to change the SQL username's password? Or how am I supposed to stay locked out of your system? Creating a GM usergroup on SQL server and adding a user for each GM you say? Well, not a bad one - but why go through all the trouble when you already have all the data you need?

That's why you have to separate the frontend from the backend logic here.

The easiest way to do this would be to implement a server component that'll speak a protocol you invent (something simple will suffice here) and act as proxy between a client you also would have to design and the database server. This server will check logins from clients, generate tokens for session sanity, check whether the requested command execution is valid (i.e. you wouldn't want people to execute random nonsense that could lock up the server) and ideally keeps an eye on server registration and unregistration in the database to queue commands or reissue commands you want to execute every time a component comes online.

Of course you can start securing your database, creating special users that can only access the tables necessary for GMtools... but hey, that's still a sub-par solution. And administrators that are capable of doing that will probably just schedule the execution of queries anyway.

[PHOENIXXXX]

looks like Suneka has heard you out and he's going to release an english version.
Thats really kind.