Tool file:

• establish secret (one of the following)
  • array(table,key_column,oauth_consumer_key,secret_column,context_column)
  • plain text secret
  • include master dance file

master dance file:

• grab token values from session if present
• grab domain from LTI POST var [‘custom_domain_url’]
• store domain in cookie in case we have to redirect
• include modified blti.php, canvasapi.php,dbaccess.php
• $context = new BLTI()
• if $context->valid (secret accepted, token retrieval attempted, db table stored in cookie, in case token is invalid)
  • $api = new CanvasAPI(token,domain)
  • if token invalid redirect to /login/oauth2/auth?redirect=get_token_domain.php
    • at this point, we have lost all our php vars, since we redirect
    • request admin  authorization
    • if granted, we land in get_token_domain
      • retrieve cookies, include dbaccess, update token in db, dance over
• else dance over

I’m trying to standardize on a set of files to use for LTI tools that require API access. Right now, I have two distinct tables that contain a column for auth tokens. The first one was intended to be a domain-specific all-purpose token. Once an admin had given permission for any of my tools, all others would be authorized automatically as the token was found in the table. Then I had second thoughts, and decided that I should store secrets and tokens in the same database, with one record per domain+toolid. That second workflow has a serious bug at the moment, which is that when a token expires or is deleted, the token is not updated in the table. It’s an easy thing to fix, but I’m hestitating just a bit because it isn’t clear to me what the best scheme really is. I could search for tokens ONLY in the token db, and stop storing tool-specific tokens. That cuts down on overall storage for me, and token management for potential adopters. It really isn’t clear to me which scheme I should standardize on.

Over the weekend, one of my core Peer Evaluation users reported a bug. When compiling the non-responders -email address list, the app was including students who had failed to submit a self-eval, even when the project was not supposed to include self-evaluation. I don’t know for sure if that bug has been there from the beginning or not. It was an easy fix to one of my database views.

One thing I really need to do over the winter session is clean out all the unused views from my peer database, and also all the unused php scripts from my peer folder. There is a lot of version clutter there. The system I have in place for my newer projects works better…separate folders for production and beta files. Better if I clone the database as well. Will need to learn much more about Git if I am to submit a Canvas Grant proposal involving a GitHub repository.

I’ve added some new features in Post’Em for Canvas.

Production

• checks for canvas id (first column in gradebook export) in addition to udsis and email to identify students
• hide first two columns in student view
• download csv template with first two columns

Beta

• View as student (row num)

Next up, in-place editing

• toggle contenteditable
• externalize css
  • in postem folder?
  • custom lti var for path?
• merge cells
• hide columns
• insert column
• insert row
• transpose student view?
• multiple tables per view