Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Single sign-on #17

Open
SolalPirelli opened this issue Mar 27, 2016 · 0 comments
Open

Single sign-on #17

SolalPirelli opened this issue Mar 27, 2016 · 0 comments

Comments

@SolalPirelli
Copy link
Member

(this is a suggestion, I'm not saying it needs to be implemented exactly like that)

Design principles:

  1. Contestants are assumed to be clumsy, but not malicious.
    They may confuse team names (especially because there are always 2-3 teams named "DROP TABLE [something]"), or sit at the wrong table.
    They will not try to impersonate other teams, or destroy sheets given to other teams.
  2. Contestants must only ever input any kind of credentials once, for the entire duration of the contest, dry run included.
  3. Team names must never be inserted into a plain text field, as they may contain non-standard characters (e.g. the "flipping table" emoji).

From the contestants' point of view:

  1. Boot into a screen with 1 field: "Please input your password".
  2. Insert the password (in a "plain" text box, no masked characters), given by contest organizers.
  3. See the corresponding team name (including contestants' full names), with a "confirm" button
  4. Click on the button.

From the client/server point of view:

  1. Prompt the user for a password on boot
  2. Ask the server to which team name it corresponds, and display it
  3. If the user confirms, send a message to the server indicating a login
  4. The server replies with some form of executable command/script that sets up any credentials-related settings

From the organizers' point of view:

  1. Export the list of teams from the contest website.
  2. Import it into the server.
  3. Put the printed password sheets on the right tables.

Some notes:

  • There should be a hardcoded special password that bypasses everything (and thus doesn't set up any credentials), so that contestants can try out the system before a contest.
  • It'd be nice to leave the password generation outside of the contest website, so that it's not bound to a specific way to do authentication.
  • This system could most likely be reused for non-contest settings, e.g. coding exams, by changing the way passwords are distributed, and perhaps allowing an optional "name" field (enabled by some special config) to integrate into any university's existing login system.
  • The judging system may not be integrated with this, but will definitely have an online "username/password" login form.
    One way to bypass this would be to have a script that sends the form (as an HTTP POST), gets the resulting cookie, and adds it to the browser's cookie store, so that users are logged in as soon as they open the website.
    A more hacky way to do it is by adding data to the stored passwords list, and finding a way to automatically send forms that are auto-completed, so that users feel like they're logged in automatically. Then the bookmark for the contest website (or even the browser homepage) can be the login page.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant