Security Codes and Text-Based Log Files

[darklorddrexx]

I've come across a website called www.Magic-League.com, where players are able to join online tournaments and so forth for free. They allow users to choose what application they wish to use as long as it adheres to the following criteria:

Deck security codes Log files for matches, that are stored in plain text. Print whether a deck is sideboarded or not at the commencement of a game. Currently they use an application called Magic Workstation, as it is the only one that meets these criterion so far. The application itself is absolutely atrocious, however. Often there are crashes, disconnections, and a myriad of other errors. Attempting to play with other users creates for a terrible experience. I play with a couple of friends there that do not yet have Octgn and even just casual play with them can be imfuriating.

I understand that the way the application functions is that once a room is started, only then is a deck loaded and that from a deck file where the side board is predefined and separate from the deck, but even so they would require something to the extent of stating the deck code and checking that the deck matches the original list.

But to the point, what would it take to implement these three things into Octgn so that online communities such as Magic-League can run their tournaments through Octgn, and other such communities might be created for other games your application has plug-ins for.

Perhaps a feature could be implemented as well, that allows a list of currently running games to be displayed, and users would then be able to join and spectate (no control over the game whatsoever, or the chat). This would make sure people who do spectate (as some do) cannot mess with the game, but also allows something like a judge to be called during a match. This feature resembles one from a site called www.duelingnetwork.com.

Thanks for your time.

[Gravecorp]

most of c# is very much like java. just forgot about exception throwing and some other small things and your ready to get down to business. Just need to do more default lib use than is usual in java.

[pg8]

Posting logs online after the game might work out actually, but it's also really useful to have them in the middle of the game if there's a dispute of some kind. Perhaps a "save log" function?

[glyphx]

Hm, fair enough, I'll look it to it. Thanks for the fast responces, and the interest in our issues. Believe me we're only the tip of the iceburg of people interested in it from magic-league. MWS is dated, time for it to die.

[glyphx]

not that I don't like save log, prob useful, could also make it force the push onto the net before the game ends at a buttons notice.

[kellyelton]

Might make it automatic, just because others might find the logs useful as well.

[Roomonkey]

G'day, Weedmonkey from Magic-League here. pg8 gave me the heads up of the github comment thread :)

What we need and why we need it (I already shot this in an email but figure it might be worth expanding):

Security codes: This is so we can make sure that a player is using the same deck they registered with each round. MWS uses a truncated MD5 hash of the file if I remember correctly, and this is all we really need :) The algorithm used would be great to, as we can then add it to the list of security codes we generate.

Log files: Judges need this to handle rulings so we can review the matches. MWS provides timed log files of players' actions as well as who initiated an action, which is ideal for what judges need to resolve the dispute. Plain text logs that can be uploaded later would be fantastic.

Print whether a deck is sideboarded at the beginning of a game: MWS provides the security code and an /sb marker if the deck is sideboarded at the beginning of each game. This is a straightforward thing to make sure people aren't being cheatyfaces and pre-sideboarding.

I'll do my best to keep a track on this thread, as I like the idea of an application that isn't riddled with bugs being used on Magic-League :D

[kellyelton]

Thanks for all the information. I want to make sure I don't waste my time going down the wrong trail(@Roomonkey I remember the e-mail, just it would help to hash things out here so they are visible, and I had a few questions)

[kellyelton]

When I have some samples of the codes, and logs I'll let you guys know so you can review them and let me know.

[pg8]

Roo, do you know if a deck file that looks like this could be read by our site? https://github.com/MagnusVortex/Standard-Playing-Cards---OCTGN/blob/master/54.o8d

[kellyelton]

what language you guys use for your site?

[glyphx]

PHP? Someone else prob better answer that :D

[Gravecorp]

if its php just parse it like a standard xml file. if your website guy doesnt know how. get a new one :P

[pg8]

Pretty sure it's php

[glyphx]

You mean you'll give us the algorithm and we'll parse it into xml for php to implement?

[Gravecorp]

No i mean the deck file is readable as an xml file so you can verify stuff. ;)

[glyphx]

oh to import it in, ok, sure. I was talking about the bit where the hash is generated.

[Gravecorp]

as in our algo will be based on that file so you can easily verify the hash and generate the same hash for verification by parsing the o8d file and doing the same calculation on it as we do.

[glyphx]

right, i thought thats what you wanted to know what the site was coded in, does that matter in that instance as well?

[kellyelton]

I was curious because I figured I could probably just create the algorithm in both languages when it's time if I have time.

[glyphx]

Fair enough.

[Roomonkey]

Website's done in PHP, and that decklist is most definitely parsable (@pg8)

[kellyelton]

It's not in that list, but if there is a sideboard, there will be a sideboard section as well...if you want an idea what the xml file could look like, it would be best to get octgn and create some decks and check out the outputs...we had an xsd at one point, but it seems to have vanished.

[brine]

ok jumping in on this a little late, just some random thoughts and suggestions:

1) In terms of the deck validation codes... what sort of security level are you looking at here? OCTGN's open-source nature would most likely reveal the algorithm code to anyone who knows what they're looking for. There could be a few implications here, namely (A) A player could get their opponent's deck validation code, decipher it, and be able to see the full contents of that deck, and (B) a crafty player could build a modified version of the OCTGN client to change the algorithm, so that the deck validation code it displays for the other players can be spoofed to whatever I want (so there's no guarantee that the validation code actually matches the deck).

2) I have an online GUID database set up the entire MTG card data that is available on OCTGN. Primarily I had this set up so websites could export decklists in OCTGN format using specific GUIDs matching those cards. I could easily add some extra features to the databases, such as querying a GUID and returning the corresponding card name, collector number, multiverseId, and/or expansion that the card is from. That should help with interpreting OCTGN's deck files into a more readable format

[glyphx]

Yeah, I remember these exploits from apprentice days... not sure what could be done about that.

[kellyelton]

The first concern isn't a problem actually.

[glyphx]

I guess you could have the algorithm that generates code have a hidden key, that only the developers and magic-league know?

[glyphx]

md5 is one-way right?

[Roomonkey]

On the first - OCTGN will be used for tournament play so the hash will need to be one-way (and yes, MD5 is one-way).

On the second - Anything to make the job easier is greatly appreciated :)

[glyphx]

As for the issue of spoofing, I think once spectator mode is in, that's almost a check against this kind of behavior, if a judge is spectating for instance, he will have access to your decklist, and could see any cards that were not supposed to be there.

[kellyelton]

Like I was saying, the issue 1 isn't even a problem, remotely.

[kellyelton]

All that information will be living server side, so the server will generate the hash and send it where it needs to go. The server will also be generating the logs, so there isn't any room for the user to tamper with anything.

[glyphx]

Right, I guess I assumed this stuff was client side, as it has always been in the past.

[kellyelton]

We have recently added the ability for each client to save their log to a text file.

[Roomonkey]

This is fantastic news! Really looking forward to seeing things develop
from here

[darklorddrexx]

Sorry to be a bother, but could I get the TL:DR update of what's happening with this?

How far along in the process of establishing the necessary requirements have y'all come? (Could be good for new people to this thread to get a full TL:DR summary, too)

Thanks. Keep up the good work

[kellyelton]

So far we have a full game log which players can access and save to a file for uploading. No deck keys or anything yet, haven't had a lot of spare time lately, but hopefully if some things pick up it can be done soon.

[glyphx]

Hey Kelly, any updates bud? Still starving for new software over here!

[kellyelton]

Sorry no, things have been pretty busy. The infrastructure is getting closer though