Ticket Authentication Strategy

From AutOKwiki

Jump to: navigation, search

This is a description of how the autOK system will authenticate the various kinds of tickets that may be used with the barcode reader.

Contents

[edit]

Purpose

The purpose of this page is to answer the following questions.

  • User ID Cards
    • What is the user ID format?
    • How does it correlate to online ID?
    • Where does authentication happen?
  • Song Tickets
    • What is the ticket code format?
    • Where does authentication happen?
    • What power does KDJ have over ticket authentication?
[edit]

Goals

In writing this description, the following concepts were kept in mind:

  • Avoid any steps that require pre-scanning of tickets. This is time consuming, and unnecessary.
  • This system could be used across multiple venues, so ticket from Venue A should not work in Venue B
  • Avoid practices that are susceptible to overflow (oops, we ran out of IDs). Consider the ultimate notion that this system could be used for years, in hundreds of Venues, and by many thousands if not millions of people someday.
  • This system should work with or without Internet access
  • Should keep as much intelligence in the back-end server as possible.
[edit]

Ticket Generation Process

  • We have a ticket generation program.
  • It generates tickets, using barcodes that meet the agreed upon format.
  • The Ticket ID format will make use of 32-bit values for instances. At a maximim of over 4 billion, this avoids the need to do prescanning and avoids the problem of overflow (running out). A single venue could never practically sell 4 billion tickets in any reasonable lifetime. Also, since every ticket is unique, photocopying used tickets will not be valuable at all.
  • The Ticket format will conform to this specification
  • With appropriate behavior in the various autOK software (autOKdj, autOKfe, autOKdvd, etc), nothing else need be done. By conforming to these rules set here, tickets will by definition be authentic until they are expired in the authentication process.
[edit]

Ticket Authentication Process

[edit]

General Ticket Authentication

The autOKdj Server will authenticate all tickets. Terminals will do none of this. Terminals will just send Ticket IDs to the Server, Server will say Yea or Nay.

This eliminates the problem of distributed data in the network (Queue a song in terminal A, then use the same ticket to Queue a song in terminal B, both songs go in cuz A and B don't talk to each other).

Also, the ticket authentication process is configurable, and therefore relies on settings that are exposed in the Server configuration panel.

We have identified 2 kinds of Tickets (User ID Ticket, Song Ticket), and both require a slightly different process. These are discussed below.

Tickets generally have a Vendor ID associated with them, so that a ticket can declare itself as having been purchased from a specific vendor.

Tickets generally have a Ticket ID associated with them, so that there may be a unique instance of any ticket.

The server will be able to either authenticate tickets (advise the terminal if the ticket is good) or use and invalidate them (use the ticket to perform a purpose, then set it's state to invalid so that it may never be used again).

The format of these HTTP posts is described in other pages, but follows a general format and is expandable for any conceivable number of "kinds" of tickets, number of venues, and number of tickets.

[edit]

User ID Ticket Authentication

The terminal talks to the server via HTTP posts. HTTP posts concerning users will contain either "text" or "ID"

If the post contains an ID, the server checks against a local file containing the list of known IDs. Where this file comes from is discussed below.

If the ID is not found in the file, the server will return data suggesting an error.

If it is found, the name is looked up and used in human readible text.

If the post contains text, server acts exactly the same as it does today.

[edit]

Song Ticket Authentication

The terminal talks to the server via HTTP posts. HTTP posts may contain ticket IDs for queues or ticket bumps or both.

For each Ticket ID, Server checks against a file full of expired IDs.

If there is no match, the ticket is used and written to the expire file.

If there is a match, the ticket is rejected.

If a single post contains multiple tickets and any one ticket is rejected, all tickets are rejected and none are expired.

The KDJ may turn off Song Ticket authentication with a preference setting.

[edit]

Server Characteristics

The following describes the features that the autOKdj server must support in order for th is strategy to work. The latest AutoKDJ Winamp Plugin Build has all of these features.

[edit]

Global Features

  • A preference tickbox, saying whether to do strict ticket authentication over HTTP posts.
  • A Venue ID field that may be filled in by the KDJ or system administrator running the server.
  • A "Skeleton" Ticket ID that may be filled in by the KDJ or system administrator running the server, specifying one ID that never needs authentication.
  • A file or database that correlates User IDs to registered Online IDs and text names of some kind.
  • A file or database that contains a list of expired tickets
[edit]

User ID Authentication Features

  • A method to specify user by ID pair (Venue ID, User ID). If URL comes in that specifies a user as a User ID, an authentication takes place
    • Compare Venue ID and User ID to values in file
    • If match found, text used is the name in the file
    • If a User ID that has a corresponding Online ID queues a song, send a message to a master user database for tracking purposes
  • If URL comes in that specifies a user as text, it just works the way it does today
  • Make system robust against the scenario where a name text happens to match a future Online ID
[edit]

Song Ticket Authentication Features

  • Server has a way to specify ticket by ID pair (Venue ID, Ticket ID)
  • If URL comes in that specifies a Ticket ID, authentication takes place
    • If strict ticket authentication is FALSE, bypass the authentication process
    • Otherwise, compare Venue ID and Song Ticket ID to values in file
    • If match found, the ticket is considered expired, and is rejected
    • If no match found, and song is successfully queued, and if the value is NOT the Skeleton ID, add that ticket entry to the expired ticket file
  • Expired tickets should come with history (when it was expired, who queued the song, what song did they sing)
  • If URL comes in that does not specify a Ticket ID, and strict ticket authentication is TRUE, reject
  • Ticket bumps will be a series of tickets that come in under the same venue ID(Venue_ID, Ticket_ID, Ticket_ID, etc)

NOTE: There seems to be a limit in the Winamp HTTP server of around 300 chars (256 maybe?) That's enough for about 5 tickets.

[edit]

Server Tracking Features

  • Server has a way to look at all expired tickets
  • Server provides a way to allow the KDJ or system administrator to unexpire any given ticket
  • Unexpiring a ticket should be such that it may be done with either keyboard/mouse or a barcode scanner, which means KDJ needs his own reader, and plugin needs code to do reading
[edit]

User Registration

  • The database of users is accessible from an Internet web page, so that customers may look up their own statistics (no private data). This implies that the User ID database should be on an Internet accessible database of some kind.
  • An end user (or karaoke customer) needs a way to print out a User ID card from the web page
  • There needs a way for user to get User ID card at the Venue
    • A new customer who does not have a User account, but wants an ID card, can get one at the venue, which is reflected in the web account
    • This user gets a card and a receipt, showing their account information allowing them to access their information from the Internet as described above.
    • The autoKDJ server could also add a User Registration View for this purpose. THIS IS NOT IMPLEMENTED
  • We may want to consider one-nite-only ID card as a backup or as simply a way to generate a temporary ID for customers who just don't need or want Internet accounts.
    • Ideally, a user could generate a one-nite-only ID card with a kiosk and a printer
[edit]

Other Info and Tidbits

[edit]

Number of Digits

We considered how long any given ID should be.

The barcode reader can read an arbitrary number of digits.

We have already determined that it can read data as large as a 2 unsigned longs ID plus an 8 bit header.

B8
5301
7343
7670
200D

We considered using UUIDs for Venue and ticket instances, but this was not practical. At 128 bytes, each UUID requires 32 characters, for a total of 66 characters per ticket. For a single barcode to hold 66 characters, it would need to be longer than 8.5 inches, or nearly a foot long. Also, with 4 bytes, the maximum number of users the 7 Bamboo website can hold is 4 billion. So, this should be plenty of possible values.

[edit]

Barcode Reader Behavior

Barcode readers typically behave just like regular keyboards. They read values and send them to the focused window and then send a WM_COMMAND with IDOK. This is identical to a user typing stuff, then hitting Enter.

Retrieved from "http://www.autokdj.com/wiki/index.php/Ticket_Authentication_Strategy"