Dawn of Light

Well, like duff suggest in this thread, let's talk about a possible DRAS (DoL Remote Administration System, if you've a better name lol ...)

We have to think about the system, how it will be implemented, how it will work, what functionalities have/should be implemented etc.

Personaly I think that the system should be OS independant; it have to run on Windows as well as on Linux.


The implementation ** my vision (or my opinion) :

What kind of DRAS ? WebBased or Program ?
I think webbased should be used, because the only thing you must have is a webbrowser, nothing else. So you could administrate your server from anywhere.

WebBasaed, but which language ? Maybe a PHP Tool is better, it's free and it's not OS dependant.

Ok, but how it will interact with the server ? That's a good question, the thing is that we have to find a module that can be used by the PHP Tool and the server to comunicate and execute the job.

Also, another thing, the database, with nhibernate, you can have various database engine, so we have to define which one will be used with the tool.

Tool's functionalities :

What's needed ? Do you want the tool to be only used by admin, or user can see their characters, etc ? For both, we need to authenticate before we can do anything, so how ? use an external login/password, or use the same as the game account?

The admin functions :
What basic function are needed by admin ?
- start, stop, "pause" and restart the server.
- create, edit, remove an account (including ban account).
- create edit, remove a player (including kick and ban).
- send announce message.
- send a message to an online character.
- view important logs.
- view and edit (could harm the server) database ?

Well, that's a good point to begin the discussion now

My suggestion would be to make the actual application a web service. A web service written in C# canl run under both mono and Windows just fine. It can sit on the same machine as DOL and do whatever it needs to do from there.

User interfaces that call the tool can be created in PHP or ASP.NET or even native Windows/Linux applications if desired that interface with the web service. Those applications will be easy to write in any platform. They can sit on the server along with the web service if desired. They can be run locally on any box anywhere if desired. People can pick whatever interface someone whips up they like the best, and still access the same core functionality exposed by the web service.

New features can be added to the web service without breaking any existing user interfaces. They all will continue to work, and will just need to be enhanced to access the new features.

Make sense?

I second Web Services. THere isn't going to be any easier way to interact with the server. Do we want to be designing packets like DAoC has? Hell no.

I know Mono can serve ASP.NET pages with xsp, but I do not know how you'd consume these web services with PHP. If they are spitting out XML, simplexml could work, otherwise, no clue.

*shameless plug* Since some institutions and schools block certain pages, and using the web can be a hassle, it might also be good to add different protocols (AIM/MSN/IRC) as a transport. This allows people who, say, can't access their page because of URL restrictions and/or port restrictions (some people host on their home computers, and their port 80 is blocked at the ISP) to use chat services, which provide an equivalent in-game setup, to do remote administration. There may be some reflection requirements for something like that, though.

Yes I would like an external service, independant from DOL (eg. running in an own process). This has the most benefits and is the most secure form.

Like this:

Client <-> RemoteAdminService <-> DOLServer

The communication protocols can be discussed. Webservices might come in handy, I second that too. I also would like to have the RemoteAdminService be plugin enabled. Eg. we could provide a HTTP Frontend plugin that communicates with the service over the WebServices and presents an HTTP layout to the user and many more things.

The service itself could communicate with the DOL server in serveral ways, open to discussion.

I suggest that DOL itself should only allow the RemoteAdminService application itself to connect to this communication facilities (to prevent possible security issues).

Hmm, thinking about it how do you plan to secure the service? Thing is every noob can look on this webbie to read how webservice works to code or even download his hackware...
Imho only way I can think about is to secure every admin command with admin password (or login and keep his IP and MAC for verification)

Imho only way I can think about is to secure every admin command with admin password (or login and keep his IP and MAC for verification)

or a Certificate login?

Imho only way I can think about is to secure every admin command with admin password (or login and keep his IP and MAC for verification)

or a Certificate login?

I do this for a living... and yes you could do that. If you want the strongest possible security then you should use certificates. But that's probably overkill here.

For a simpler mechanism, this is pretty common:

1) Web service exposes an authentication method. You pass it a userid, and a password and it returns a "session" ID to you (typically a GUID). You do this over HTTPS if you want the best security.

2) Web service stores that "session id" to a table with an expiration timeout. (20 minutes or whatever)

3) All other methods of the web service require a session id to be passed into it. So the client needs to remember the session id it got back from the authentication and it then passes in that "session id" with every request as a paramater or as part of an xml document that describes the request (these methods can be invoked over https or not... even if someone packet logs the guid it's not going to be valid in a little while anyways).

4) For every request that session id is validated against the db. You can bump the timeout for that session id if you desire - so it doesn't timeout unless the person stops using the web service for however long the timeout is. Or not if you want a hard timeout.

5) A logout method that takes the session id can terminate it at any time.

6) A background task (in sql server it's called a "job" - you attach it to a stored procedure or a dts package) looks for expired sessions every so often and deletes them from the table. If desired then during a nightly maintenance window it can kill them ALL to prevent a robot from permenantly keeping a session alive. (forces re-authentication).

That's about it, tweak to your needs.

(Note that you could pass in the userid/password with every request, but to be secure that requires full time HTTPS, where the above mechanism only requires it for the initial authentication).

You can use a self-signed certificate, too. You don't need a certificate from a major CA because all your admins/gms know that this will be self-signed; there is nothing to prove.

or You can get free certificate from CACert. (http://cacert.org)

or You can get free certificate from CACert. (http://cacert.org)

Are cacert certificates considered as comming from a trusted certificate authority by Windows or does it treat it the same as a self signed certificate? (IE, it nags you...)

Are cacert certificates considered as comming from a trusted certificate authority by Windows or does it treat it the same as a self signed certificate? (IE, it nags you...)

same as trusted certificate authority by Windows. but you must register root certificate before use that.

Either or.

The service itself could communicate with the DOL server in serveral ways, open to discussion.

I suggest that DOL itself should only allow the RemoteAdminService application itself to connect to this communication facilities (to prevent possible security issues).

What we have done in scenarios like this lately has been to expose the server interface via .NET remoting on a port over the local loopback interface and/or only open a port to the remoting interface from specific IP address(es).

So the web service talks to the "server" via remoting over that port, but nothing else can access that remoting port.

.NET remoting works with Mono.