9 replies to this topic

[mappy]

DCWebUI

Are you an NMDC hub owner? Give your users a javascript web interface!

Javascript cannot open a direct TCP connection by itself. Through AJAX, however, it can retrieve urls and incorporate the response into the current page. DCWebUI uses a proxy program (supplied) that maintains connections server-side, and provides a HTTP api to communicate with the web interface.

Binary, source code and instructions available from http://code.google.com/p/mappy/

[Mek]

sooo, what is this good for? is it a chat-only "client" which can be only run on the same computer as the hub?

[mappy]

Mek
Well, no... it's a web interface for a hub. Your users can visit a web page, log in and chat away on a hub of your choice.
Because of the way html/javascript security works, the current implementation needs a proxy server. For simplicity's sake i forced it to run on the same server as the hub, but it's really arbitrary.

Toast
I get the message I'm copying everything to http://code.google.com/p/mappy/ .
I'm still planning to stick with NMDC for the forseeable future, though. The same web interface should work fine with an ADC hub if the proxy backend is switched out, since it does all the real work.

[FlipFlop]

There seems to be a bug in calculating or formatting the $Key:

$Lock was:
EXTENDEDPROTOCOL_FLEXHUB_MULTIPROTOCOL_ML26

Received :
$Key ÑÀ° A ѱ±ÀÀ01‘ Ñ
ÑqÑ!‘Ñ‘ ѱ±ÀÀ01!ç@a³e´1q¡/%DCN096%/åáá

Should have been:
$Key DÑÀ° A ѱ±ÀÀ01‘ Ñ
ÑqÑ!‘Ñ‘ ѱ±ÀÀ01!ç@

It looks like the key isn't calculated at all, just sending the same key everytime.

[mappy]

FlipFlop, on 26 April 2011 - 10:32 AM, said:

There seems to be a bug in calculating or formatting the $Key:

$Lock was:
EXTENDEDPROTOCOL_FLEXHUB_MULTIPROTOCOL_ML26

Received :
$Key ÑÀ° A ѱ±ÀÀ01‘ Ñ
ÑqÑ!‘Ñ‘ ѱ±ÀÀ01!ç@a³e´1q¡/%DCN096%/åáá

Should have been:
$Key DÑÀ° A ѱ±ÀÀ01‘ Ñ
ÑqÑ!‘Ñ‘ ѱ±ÀÀ01!ç@

It looks like the key isn't calculated at all, just sending the same key everytime.

It'll send the same key if the lock doesn't change. It looks like they're the same for most of it, i wonder what's going on?
My lock2key is compatible with PtokaX, at least, although i know it's one of the more lenient hubsofts.

Here's what's going on under the hood, in nmdc.cpp;

//NMDCHub::handle_command(char* szCommand)

if (strcmp(szCommand, "$Lock")==0) {
		push_event(NMDC_SYSTEM_MSG, "\0", "Found a hub.");
		char key[BUFS];	parse_lock(szCommandNext, key, BUFS);
		sprintf_s(szSay, BUFL,
				 "$Supports NoGetINFO UserIP2|$Key %s|$ValidateNick %s|",
				 key, self.szNick);
		SayExplicit(szSay);

// ...


void NMDCHub::parse_lock(char *lock, char* destBuff, int out_buffsize) {
	int len = strlen(lock);
	char* key = new char[len + 1];

	//lock-to-key transform
	for(int i = 1; i < len; i++) { key[i] = lock[i] ^ lock[i-1]; }
	key[0] = lock[0] ^ lock[len-1] ^ lock[len-2] ^ 5;
	for(int i = 0; i < len; i++) { key[i] = ((key[i]<<4) & 0xF0) | ((key[i]>>4) & 0x0F); }

	//sanitise
	memset(destBuff, 0, out_buffsize);
	char* newkey_p = destBuff;
	for(int i = 0; i < len; i++) {
		switch(key[i]) { 
			case 0:  case 5:  case 36:  case 96:  case 124:  case 126:
				sprintf_s(newkey_p, out_buffsize-(newkey_p-destBuff)-1, "/%%DCN%03d%%/", key[i]);
				newkey_p += 10;
				break;
			default:
				*newkey_p = key[i];
				newkey_p++;
		}
	}
	*newkey_p = '\0';

	//tidy up
	delete key;	key=NULL;
}

I have an alternate nmdc core that uses STL strings instead of <cstring>, guess i should transition dcwebui over to that core instead as well, but to be honest i don't like this approach as much as flexdc, my flash-based webui. This is more cumbersome, and the one advantage that javascript has over flash, working on mobile devices, doesn't seem to apply to me personally (i have a S40-Webkit).


EDIT: Like you mentioned in the flexdc thread, this could be caused by locale settings.

Edited by mappy, 29 April 2011 - 12:28 PM.

[PPK]

mappy, on 28 April 2011 - 01:00 AM, said:

My lock2key is compatible with PtokaX, at least, although i know it's one of the more lenient hubsofts.

Are you sure ? Because PtokaX not checking Key when client is using EXTENDEDPROTOCOL (sending $Supports to hub)

[mappy]

Huh, OK. Thanks for the information.

I guess that's why it's always worked, then, since the core always uses EXTENDEDPROTOCOL/$Supports, and PtokaX would just be ignoring it if it's calculated slightly incorrectly. I'll look into this bug further, since it's going to affect all my C++ NMDC projects. Anyway, it still works on PtokaX for the meantime.

P.S. Any ETA on new PtokaX stable release? : )

[mappy]

I've fixed the bug in my lock2key. It should connect fine to most hubsofts now (tested with PtokaX, YnHub, and FlexHub). There's an updated version of dcwebui available with the changes applied (although, with no other changes).

The bug also applies to ut2dc, so there's a new version of that now, too.

[mappy]

Semi-major update (r4) with some much-needed attention.

Added protocol buffering, proper sanitisation, private message support, wider compatibility with hubsofts and browsers, and removed the jQuery dependency. It should be a lot more stable and useful now.

Instructions are now contained with the download.


State of DC on mobile devices
As far as I know, this (and MekDC) are the only ways of getting DC on an iOS device. Android has this, the flash flexDC, and there are at least two android DC clients in development. Blackberry and other J2ME devices can use jmDC. I plan on compiling FlexDC as a native application for both Android and iOS with the new flash builder 4.5 update soon.