jwodicka / mural-legacy Goto Github PK

Character ownership should function independent of implementation.

CharacterOwnershipIndex should be refactored into an interface for objects that can provide ownership data, and an initial implementation that can read such data from a simple format - initially, SQLite.

Mural emits a lot of debug output to the console. This should be replaced with a sensible, configurable logging class - either something good that we can just pull in, or something simple we build ourselves.

An admin console is the first service that lives entirely within Mural.

Users with access to the admin console can:

• shut down the Mural server politely
• add / remove user accounts
• add / remove characters and permission to them
• add / remove remote services ("worlds")

Other features the console wants? Syntax thoughts on the console? This is the explicit administrative interface to the system, so anything we find ourselves wanting to do to a running Mural instance is fair game to go in here.

This also adds, implicitly, our first notion of a privileged admin user class: users who have access to a character on console are capable of using the console powers.

A number of the objects in the system currently construct other objects to help - particularly, connections construct parts of the message pipeline, and things that need data construct the relevant providers to go out and get it from the DB.

While much of the code is already abstracted into interfaces with concrete instances, and does a decent job with manual dependency injection, we need to improve the dependency injection, and wrap it all in an IoC container to give us a point from which to manage it.

I'm currently looking at Ninject - http://ninject.org/ - as a way of doing that, and some TODOs littering the code make reference to it - but if you have an argument for another IoC container, we can have that discussion.

Right now, Mural attempts to autodetect the current network configuration in a fragile way. It should instead be configured explicitly by reading from a config file.

Right now, we can connect to remote services that use telnet-over-SSL (FurryMuck has been our test case for this), but it's not currently possible for an end-user to connect with an SSLed connection.

We need to enable SSL for incoming connections; telnet has no security against packet-sniffing, and it would be more appropriate to pass credentials in a secure fashion whenever possible.

I accidentally connected an SSLSession to the non-SSLed version of the remote, and discovered that the system ends up in a badly inconsistent state. Didn't investigate much, but it's clearly a problem.

• Investigate what actually happens to the message chain when SSL auth fails (e.g., because the other end doesn't support it)
• Propose a sane alternative. (This will almost certainly be some class of failure.)

Unacceptable results are:

• Remain connected to a session that's not actually going anywhere and also isn't parsing.
• Anything that brings down Mural.

Ideally, we want to give a hint to the user (and the admins, via the log) of what happened here. This might happen because of a remote-side failure, but it it's recurrent for a given server, it's likely that whatever is on the other end just isn't talking SSL.