04 Apr, 2011, Twisol wrote in the 181st comment:
Votes: 0
quixadhal said:
You might want to take a look at how Cratylus modified anyterm to work around the IP address masking thing. I think the general idea is to pass the actual IP (which the server proxy knows) along as data, which the game server can then plug in instead of trying to query the peer address (which is the proxy).

Hmm, where can I find this? I've never heard of anyterm, and I wouldn't know where to find Crat's changes.

The IP-pass-along you described is the basic mechanism of how this works, right. How easy is it to spoof it though? That is, can anyone take advantage of the IP-pass-along mechanism to lie to the MUD about their IP?
04 Apr, 2011, chrisd wrote in the 182nd comment:
Votes: 0
plamzi said:
Any links ready to explore, Twisol?


DecafMUD uses WebSockets and resorts to Flash. I think the author was planning on moving to Socket.IO for the networking. Source code for funtimes.
04 Apr, 2011, quixadhal wrote in the 183rd comment:
Votes: 0
Twisol said:
Hmm, where can I find this? I've never heard of anyterm, and I wouldn't know where to find Crat's changes.

The IP-pass-along you described is the basic mechanism of how this works, right. How easy is it to spoof it though? That is, can anyone take advantage of the IP-pass-along mechanism to lie to the MUD about their IP?


Well, it's your web server, so it's however secure your web server is. Here's a link to what Crat did for this… the key is using server side includes to allow the web server to plug in the origin of the request.

The article is specifically geared towards using anyterm + dead souls, but the idea should be adaptable to anything else you want.
04 Apr, 2011, Twisol wrote in the 184th comment:
Votes: 0
Twisol said:
Well, it's your web server, so it's however secure your web server is. Here's a link to what Crat did for this… the key is using server side includes to allow the web server to plug in the origin of the request.

Well, no, I'm talking about the general mechanism, and the security of the MUD accepting the IP address. If it can accept a replacement IP from Aspect, there should be a mechanism in place to keep untrustworthy sources from trying to provide a replacement IP to the MUD as well.
04 Apr, 2011, Twisol wrote in the 185th comment:
Votes: 0
chrisd said:
plamzi said:
Any links ready to explore, Twisol?


DecafMUD uses WebSockets and resorts to Flash. I think the author was planning on moving to Socket.IO for the networking. Source code for funtimes.

I have actually spoken with both the creators of DecafMUD and PHudBase, and I'm aware of their projects. I just forgot about them sometime before the turn of the year. :biggrin: They are both rather cool projects, but I don't know how seriously they're being worked on. DecafMUD was last updated 3 months ago, and PHudBase even longer. They both seem (as far as I can tell) to be geared towards direct customization and embedding into your own page, whereas Aspect is meant to live in one place and be a central repository of sorts. I'm sure there are pros and cons to both approaches.
04 Apr, 2011, chrisd wrote in the 186th comment:
Votes: 0
Twisol said:
chrisd said:
plamzi said:
Any links ready to explore, Twisol?


DecafMUD uses WebSockets and resorts to Flash. I think the author was planning on moving to Socket.IO for the networking. Source code for funtimes.

I have actually spoken with both the creators of DecafMUD and PHudBase, and I'm aware of their projects. I just forgot about them sometime before the turn of the year. :biggrin: They are both rather cool projects, but I don't know how seriously they're being worked on. DecafMUD was last updated 3 months ago, and PHudBase even longer. They both seem (as far as I can tell) to be geared towards direct customization and embedding into your own page, whereas Aspect is meant to live in one place and be a central repository of sorts. I'm sure there are pros and cons to both approaches.


I'm a big fan of web-based MUD clients - the more the merrier! I figured plamzi would be interested in Decaf since it's doing the old avoid-Flash-and-Java-like-the-plague thing, same as you seem to be doing with Aspect. :smile:

Using a proxy on the server-side like the Decaf demo does is a neat thing, since it means you can connect to any MUD you choose, regardless of their support for things like Flash XMLSockets, WebSockets or Socket.IO. Such an approach also makes it trivial to develop either a generic client for use with any MUD (like you seem to be doing) or a custom client for one specific MUD without having to change the fundamentals of your code.

These last two pages prompted me to write a Socket.IO plugin for Decaf. :smile:

Honestly, MUDding in the browser is awesome.
04 Apr, 2011, KaVir wrote in the 187th comment:
Votes: 0
chrisd said:
Honestly, MUDding in the browser is awesome.

I must admit, I actually don't like mudding from a browser. Not sure why, perhaps because I always end up accidently opening a new page or clicking 'back'. It just doesn't feel comfortable.

However for bringing in new players, I think a browser-based client is superb, and a natural evolution of the "no download necessary" maxim that was one of the defining characteristics of old-school muds. These days, new players are more likely to have a web browser than a telnet client, and the former offers far better support for interface customisation.

I've tried DecafMUD and PHudBase, and they both show great promise, but sadly it does look as if their developers have lost interest. I'm also still clinging to the hope that Orrin will extend FMud with some of the cool features he used in the Maiden Desmodus client. Or perhaps Twisol will finish and release his project. I think there is a definite market for a generic browser-based client with a customisable GUI, it's really just a matter of who does it first.
04 Apr, 2011, Twisol wrote in the 188th comment:
Votes: 0
KaVir said:
chrisd said:
Honestly, MUDding in the browser is awesome.

I must admit, I actually don't like mudding from a browser. Not sure why, perhaps because I always end up accidently opening a new page or clicking 'back'. It just doesn't feel comfortable.

I use Chrome on Linux, which disables that backspace behavior. I'm definitely in the minority, it's just… it's surprising, because when they first changed it I was really against it. Now I realize how liberating it is to not have to worry about that. Since you brought it up, I'll make a note to provide an option to prevent the default Backspace behavior when you're using Aspect. Thanks for the input!

Beyond that, I'm honestly curious why browser-based MUDding bothers you. I've been using it a lot, and I usually forget I'm in the browser altogether. Would you be willing to give Aspect a try when it goes live?

As a tangential point, most of the browser-based clients I've seen are really for new players… and that's it. They're pretty, but (so far) seriously annoying for doing serious stuff with. MUSHclient is a big inspiration for me in that department (sans the somewhat sucky UX), and I really want Aspect to be a serious client.

I need to cannibalize DecafMUD's ANSI support though. :devil: (Edit before post: Gawd is the rendering slow though. I wonder if it's the network latency or something else, because I've been using Aspect on localhost. Maybe I should put it on a Linode just to see.)

chrisd said:
Using a proxy on the server-side like the Decaf demo does is a neat thing, since it means you can connect to any MUD you choose, regardless of their support for things like Flash XMLSockets, WebSockets or Socket.IO. Such an approach also makes it trivial to develop either a generic client for use with any MUD (like you seem to be doing) or a custom client for one specific MUD without having to change the fundamentals of your code.

I just played around with DecafMUD a little bit, and it's definitely doing the same kind of middle-man proxy. Now I'm curious how it handles the IP shadowing problem (if at all).
04 Apr, 2011, chrisd wrote in the 189th comment:
Votes: 0
Twisol said:
I just played around with DecafMUD a little bit, and it's definitely doing the same kind of middle-man proxy. Now I'm curious how it handles the IP shadowing problem (if at all).

The server-side stuff for the proxy isn't part of DecafMUD. So no, it doesn't handle the IP shadowing problem. The proxy software (GreenLantern in Python, RedLantern in Node.js) may or may not handle the IP shadowing, but I suspect that it doesn't (hard to say because the code is floating in the ether somewhere and I didn't bother to save it when I saw it).
04 Apr, 2011, KaVir wrote in the 190th comment:
Votes: 0
Twisol said:
Beyond that, I'm honestly curious why browser-based MUDding bothers you. I've been using it a lot, and I usually forget I'm in the browser altogether. Would you be willing to give Aspect a try when it goes live?

Yes of course, I still think browser-based clients are a great idea, and if the interface for Aspect can be customised in a similar way to MUSHclient or Mudlet then I'd definitely be interested in using it to target new players.

I spoke to Bo Zimmerman recently, and he showed me his Siplet client, which has decent MXP support. Although it's currently locked to CoffeeMUD, he did discuss the idea of turning it into a general client - that would be pretty nice, even though I'm not a big fan of inline graphics.

There's also that ScapeFX client, which could have been a big hit if the developer hadn't priced himself out of the market. The project seems to have stagnated now though.


Twisol said:
As a tangential point, most of the browser-based clients I've seen are really for new players… and that's it. They're pretty, but (so far) seriously annoying for doing serious stuff with. MUSHclient is a big inspiration for me in that department (sans the somewhat sucky UX), and I really want Aspect to be a serious client.

I suspect most mud owners don't really care what clients people use - it's really the players you'll need to convince.
04 Apr, 2011, plamzi wrote in the 191st comment:
Votes: 0
chrisd said:
plamzi said:
Any links ready to explore, Twisol?


DecafMUD uses WebSockets and resorts to Flash. I think the author was planning on moving to Socket.IO for the networking. Source code for funtimes.


Nice! Wish I'd known about DecafMUD before I wrote my own Flash object (ActionScript is one of the few languages I can totally do without learning).

It seems that WebSockets is currently disabled by default even in browsers that do support it, so my guess is resorting to Flash happens pretty much always for casual users, at least for now. I'm assuming that Socket.IO is entirely server-side and it would be great not to place any demands on the end user's browser.

As for who web clients are for, it seems that mine will be used a lot more by regular/power players than by new ones. People on the move during the day log in from various locations, one of them being the web app. For that reason, I'm adding features to the server that are normally the domain of advanced mud clients. A few days ago, I added delay timers, and they can now be used regardless of client. Planning to do the same for triggers. This seems like the only sensible way to go about supporting multiple custom clients.
04 Apr, 2011, chrisd wrote in the 192nd comment:
Votes: 0
plamzi said:
It seems that WebSockets is currently disabled by default even in browsers that do support it, so my guess is resorting to Flash happens pretty much always for casual users, at least for now. I'm assuming that Socket.IO is entirely server-side and it would be great not to place any demands on the end user's browser.


Socket.IO chooses the most appropriate method and uses that. It uses WebSockets and Flash, but has more backups in case those options are unavailable. It claims to work on every major browser (even mobile browsers), which is really nice. There will always be browser requirements, but it seems like more and more of them are becoming standard browser features.
04 Apr, 2011, Cratylus wrote in the 193rd comment:
Votes: 0
Twisol said:
Twisol said:
Well, it's your web server, so it's however secure your web server is. Here's a link to what Crat did for this… the key is using server side includes to allow the web server to plug in the origin of the request.

Well, no, I'm talking about the general mechanism, and the security of the MUD accepting the IP address. If it can accept a replacement IP from Aspect, there should be a mechanism in place to keep untrustworthy sources from trying to provide a replacement IP to the MUD as well.


If I remember correctly, your system involves a proxying server you, Twisol, run, and therefore you trust it because
you know you will not lie to outbound servers about the IP's for incoming clients.

What I think Quix is saying is that in terms of being sure about the trustworthiness of IP information is that
if you get an inbound connection from a specific IP and then forward it to some target, the assurance that
the IP is really the right IP is no more or less compromised than your ability to keep your own proxying
server from lying. It's garbage in garbage out.

I do not want to seem like a naysayer or whatever, but I think that relying on human intensive methods
(registration, connection monitoring) to sanitize your proxy is a non-starter right from the get go. If you
were to explain to me an automated method to know what IP a connection comes from when I accept
a connection from your proxy, that lets me not have to rely on your diligent and constant monitoring and
registering of people. I'd rather rely on a system that lets me control whose IP gets banned, rather
than hope Twisol is totally on the ball at all times.

The system Quix suggests is one example of a step in that right direction, but I'm not sure it's
all that applicable in your case, as it relies on telopts/subneg and the muds you presumably will
service may not all want to recode their networking for you.

What they might be willing to do is recode their login handler, such that they trust your (Twisol's)
IP address to provide them login information of this sort:

<ip address><special string><new player's name>

e.g.: 1.2.3.4@joebob

The mud can strip out the header and parse it, and thereby know that the incoming connection
from your trusted proxy originated from 1.2.3.4 which actually belongs to some chump we've been
trying to ban for months but he keeps finding proxies to evade our countermeasures. It can then
reject the connection.

Alternately if that's a safe IP, it can allow it to continue as if joebob had connected directly.

If you don't allow your end user mud targets to control access on their own, you're going to have
a tough time because you will need to demonstrate why they should trust you to handle their
access controls as diligently as they would themselves.

-Crat
http://lpmuds.net
04 Apr, 2011, Cratylus wrote in the 194th comment:
Votes: 0
Cratylus said:
The mud can strip out the header and parse it, and thereby know that the incoming connection
from your trusted proxy originated from 1.2.3.4 which actually belongs to some chump we've been
trying to ban for months but he keeps finding proxies to evade our countermeasures. It can then
reject the connection.


If you just looked up 1.2.3.4 to see who owned it, you have to admit it.
04 Apr, 2011, Stendec wrote in the 195th comment:
Votes: 0
Huh, neat. More conversation with DecafMUD mentioned. ^^

As far as work being done on Decaf goes… unfortunately, I got busy. First, with work. Then, because someone finally talked me into playing Minecraft. (That game devours lives.) Between those, my personal coding time lately is limited. Mainly I've been helping with development of Pants and a fancy 3D game idea I had (eew, graphics, I know).

Now, Twisol, you say that Aspect is meant to live in one place. Really, that isn't hard to do with DecafMUD. Like my demo page does, all you really need to do is host a proxy server for connections, which you'd need to do anyways, as the only real way to create a socket in a browser without all sorts of security stuff is Java (or perhaps Silverlight? But definitely a browser plugin). By setting up the page that hosts the DecafMUD instance differently, it would be easy to customize it for different MUDs. So far as the IP shadowing problem goes, my current proxy code doesn't support that, but it'd be rather trivial to implement if there was a standard way to send those IPs to the end server.

As for the 'Gawd is the rendering slow though.' comment… well, I suppose it might be. But I suspect it's just the network latency making it slow. I'm hosting that from my home connection, because I'm silly, and I have a pretty horrible ISP. The client's code, discounting network latency, is able to chunk through (on my admittedly fast PC) 437,728 bytes of ANSI-littered data in roughly 140ms. The performance links on http://decafmud.kicks-ass.net/demos.html eliminate latency as a variable from the testing. They work by loading a file from the server completely before timing how fast it takes to push that file through DecafMUD's socketData function, essentially tricking Decaf into thinking the data came from its socket handler.

Feel free to use the display code if you'd like though. Even though it isn't fully VT-ish (cursor movement commands will be the death of me), I'm pretty happy with how it works.

One last thing I'd like to point out, is that Decaf's fully plugin oriented, including the user interface, so someone could write an interface plugin for serious users. I was actually thinking of writing one myself, using MochaUI, before I got busy with things.

All this said, I wish you luck with your project.
04 Apr, 2011, plamzi wrote in the 196th comment:
Votes: 0
Cratylus said:
Cratylus said:
The mud can strip out the header and parse it, and thereby know that the incoming connection
from your trusted proxy originated from 1.2.3.4 which actually belongs to some chump we've been
trying to ban for months but he keeps finding proxies to evade our countermeasures. It can then
reject the connection.


If you just looked up 1.2.3.4 to see who owned it, you have to admit it.


To add a (somewhat unique) perspective on this issue, as the admin of a server whose player base consists mostly of people playing over mobile devices, I know that IP is near-worthless. All a mobile user needs to do is stop/start their 3G/4G connection to get a new IP. A desktop power user will find it only marginally harder to get a new IP, and will probably have a limited supply of those, but still can give the admin a run-around and waste his/her time.

I've been freezing chars as the ultimate punishment and working towards requiring a common unique user id, such as an email address, to key off of for enforcing bans. To me, any methods relying primarily on IP are, at this point in time, more trouble than they're worth.
04 Apr, 2011, Cratylus wrote in the 197th comment:
Votes: 0
plamzi said:
as the admin of a server whose player base consists mostly of people playing over mobile devices, I know that IP is near-worthless


I agree the tools we have are imperfect.
04 Apr, 2011, David Haley wrote in the 198th comment:
Votes: 0
Quote
I've been freezing chars as the ultimate punishment and working towards requiring a common unique user id, such as an email address, to key off of for enforcing bans.

Unless you have some further authority, such as a credit card number, it's unclear why having a common user id does anything other than bump the same problem up a layer. After all, I could otherwise simply create other users…
04 Apr, 2011, Cratylus wrote in the 199th comment:
Votes: 0
Oh, and by the way….
04 Apr, 2011, Cratylus wrote in the 200th comment:
Votes: 0
180.0/275