Skip to content

Server Communication

jgat edited this page Dec 11, 2014 · 5 revisions

Introduction

MyPyTutor has an online component, primarily used to submit solutions and check results of previous submissions.

The MyPyTutor server runs through a single URL, and different types of requests are made through different action fields in the GET/POST headers. If there is no action field, the server responds with an error message.

Authentication

Authentication of users in MyPyTutor is tied into the user account management at The University of Queensland, using the EAIT Web Authentication system.

Checking authentication

When a user is authenticated, HTTP requests will be sent with a cookie named EAIT_WEB. The server will send the cookie to a backend authentication server, which will respond with a JSON blob containing the user's details, including their username, human name, email address, and other details.

Log in process

Users will be asked to log in to MyPyTutor if either (a) they select the "login" menu option, or (b) they attempt to make GET/POST requests without being logged in.

When logging in, the following exchange is made:

  1. The client makes a GET request to the server with action=userinfo.
  2. If the EAIT_WEB cookie is not provided or is invalid, the server responds with a redirect to a URL in the domain auth.uq.edu.au, which contains an HTML form used to log in. If the URL of the response is not in the domain auth.uq.edu.au, then the user is already authenticated to the EAIT system (go to step 9).
  3. The client opens a dialog window asking the user to provide their username and password, and waits for the user to click "Submit".
  4. The client parses the HTML of the response in step 2 to extract a <form name="f" ...> tag, and all the <input> tags within the form.
  5. The client makes a POST request to the action URL of the above form, with the username/password the user entered. The response will be another HTML page.
  6. If the response contains another <form name="f" ...> tag, the credentials were invalid. The client then shows an error message to the user and allows them to re-enter credentials into the dialog (go to step 3).
  7. If there are no <form name="f" ...> tags, the credentials were valid. The client extracts a <form action="https://api.uqcloud.net/saml/consume" ...> tag, and all the <input> tags within the form, and submits the form using a POST request.
  8. The response sets the EAIT_WEB cookie, then redirect the user to the original GET request in step 1.
  9. The response contains a JSON object containing the user's username and human name. This will then be displayed to the user in the application ("Logged in as: XXXX").

Note that the MyPyTutor server script only plays two roles in this exchange: redirecting the user to the login form in step 2, and responding with the JSON object in step 9. All other client/server interaction is done with the UQ authentication system.

If any assumptions fail (i.e. the HTML parser cannot find the necessary <form>s), the client will raise an exception and prompt the user to contact the maintainer. This error could occur if UQ redesigns their login forms.

Log out process

Users can log out by selecting the appropriate menu item. The following exchange is made:

  1. The client sends a request to http://api.uqcloud.net/logout. This will expire the user's EAIT_WEB cookie.
  2. The client removes the "Logged in as: XXXX" which is displayed to the user, and replaces it with "Not logged in".

Non-UQ Users

Legacy versions of MyPyTutor have their own built-in user account system, with an independent username/password storage. People wishing to use MyPyTutor outside The University of Queensland's EAIT faculty should either adapt MyPyTutor to their own authentication systems, or adapt this legacy account system.

Server Interface

The MyPyTutor server will generate responses according to the action field of GET/POST requests. The request will either succeed, with response text preceded by mypytutor>>>, or fail, with response text preceded by mypytutor_error>>>.

The following actions are supported, with extra required fields in parentheses:

  • get_tut_zip_file(), which responds with the URL of the ZIP file containing tutorials.
  • get_mpt34(), which responds with the URL of the ZIP file containing the current version of the MyPyTutor client, compiled into Python 3.4.
  • get_version(), which responds with the version number of the most recent MyPyTutor client.

The following actions require the user to be authenticated:

  • userinfo(), which responds with details about the currently logged-in user.
  • upload(code, problem_name), which is used to upload the user's code for online storage. (Errors if > 2kB of text is given.)
  • download(problem_name), which is used to download previously uploaded code. (Errors if there is no code saved for that problem)
  • submit(tut_id, tut_id_crypt, tut_check_num, code), which is used to submit a problem which the client has marked as correct. (Errors if already submitted; tutorial isn't listed on the server; or tut_id doesn't match tut_id_crypt.)
  • show(), which responds with information about the student's submissions (on-time/late/unsolved).

A number of administrator actions are also supported. Administrators are specified by a whitelist on the server.

  • match(match), which gives a list of users whose details contain a given string.
  • unset_late(the_user, problem), which overrides a user's late submission flag. (Errors if user hasn't submitted or wasn't marked late.)
  • results(), which gives a list of results for all users.
  • get_user_subs(the_user), which gives a list of submissions for a given user. (Errors if the user has no information.)