LTI-plugin: {user_id: {consumer_1, consumer_2, consumer_3} } tietokanta
Ongelman kuvaus
LTI-pluginin tarvitsee muistaa Käyttäjien + Tool Consumereiden identifikaatio.
Tämä tarvitaan mm. siksi, että kun Tool Provider palauttaa arvolauseita TIMiin päin, tarvitsee tietää kenen arvolause, mihin kurssiin, mihin sisältöön, mihin tehtävään, ja miltä sivustolta. Jos näistä ei pidetä kirjaa, ei ole mitään mahdollisuutta tietää mikä kuuluu kenellekin.
Hyvä puoli on se, että sessiot ovat voimassa vain rajatun ajan (suositus 90 minuuttia) jonka jälkeen ne voidaan unohtaa -- tai mahdollisesti uudelleenautorisoida backendista.
TIM -> Moodle
TIMin päädyssä ennen kun aletaan Tool Consumerilla muodostamaan yhteyttä, YAML sisältää toistaiseksi:
'lti_message_type': 'basic-lti-launch-request'
'lti_version': 'LTI-1p0'
'launch_url': "http://timstack.it.jyu.fi:8080/moodle/local/ltiprovider/tool.php?id=1"
'-consumer_secret': '__lti_secret__'
'-consumer_key': '__consumer_key__'
'resource_link_id': 'tim.jyu.fi'
'lis_result_sourcedid': '__sourcedid__'
'lis_outcome_service_url': "http://timstack.it.jyu.fi/grades/"
'lis_course_offering_sourcedid': 'DD-ST101'
'lis_course_section_sourcedid': 'DD-ST101:C1'
'lis_person_contact_email_primary': 'jbaird@uni.ac.uk'
'lis_person_name_family': 'Baird'
'lis_person_name_full': 'John Logie Baird'
'lis_person_name_given': 'John'
'lis_person_sourcedid': 'sis:942a8dd9'
'lis_result_sourcedid': '__sourcedid__'
Oikeasti nuo kontaktitiedot on oletettava kaikille käyttäjille samoiksi (esim. sukunimi ja etunimi ovat molemmat user_id
jonka TIM kertoo pluginille.) Toinen vaihtoehto olisi se, että TimServer alkaa välittämään hiljaisesti taustalla muutakin informaatiota. Nykyhetki ei ole ongelma, koska samannimisiä käyttäjiä saa moodlessa olla niin paljon kuin haluaa. Oikea identifioiminen Moodlen päässä tapahtuu TIMin hiljaisesti reitittämään tietoon user_id
.
Parsittuun YAMLiin lisätään OAuth-parametrejä Python-koodissa seuraavasti:
oauth_consumer_key=<Moodlen/TIMin avain>
oauth_signature_method="HMAC-SHA1"
oauth_timestamp=<kellonaika>
oauth_nonce=<KERTALUONTOINEN>
oauth_version=1.0
oauth_signature=<laskettu signature>
oauth_callback="about:blank"
oauth_body_hash=<laskettu hash>
Moodle -> TIM
Moodle välittää tämän arvosanan parametrina annettuun osoitteeseen HTTP POSTINA, jonka Headereihin on lyöty Authorization
. LtiServer on ainoa looginen paikka mihin tämä tieto voidaan Tool Providerilta ohjata. Arvolauseen palautusosoite tulee YAMLissa (tai hard-koodattuna Pythonissa) parametrissa lis_outcome_service_url
. HUOM. Tämä on täysin eri asia kuin Pythonissa myöhemmin lisättävä oauth_callback:"about:blank"
.
Tällä hetkellä LtiServer nappaa XML:nä tulevat arvosanat jotka reititetään timstackiin /grades
reittiä pitkin. Sen jälkeen LtiServer kaivelee HTTP Bodysta XML:n esiin. Sen jälkeen samasta HTTP POSTista kaivetaan headerit esiin, jotka sisältävät OAuth-tiedot. Nämä (ilmeisestikin?) pitää vahvistaa oikeiksi consumer_key:tä ja lti_secrettiä vasten Python-koodissa, joten OAuth-salausavaimen ja paluuviestin välille tulisi muodostaa myös linkki.
Kaikki autentikaatiotiedot ja voimasasolevat yhteydet tulevat tähän käyttöön olemaan vain Pluginin lokaalissa muistissa pyörivä Python dictionary. Jos TIM\plugin\docker\python tukee jotakin aloitus- ja lopetusmantraa jota kutsutaan aina kun plugin sammuu\käynnistyy, nämä tiedot on mahdollista kirjoittaa tiedostoon, mutta tähän hätään riittänee että se muistaa edes käynnissä ollessaan ne.
2 Consumeria jolla muisti
-
Toteuta kahden Consumerin välinen erottelu. -
Tallenna kaksi erillistä Consumeria muistiin. -
Palauta haluttu Consumer JavaScriptille reittiä /getform
halutuilla?parametri=tunniste
-parametreilla.
MUISTIO
-
Miksi GET-parametreissa syötetty 'undefined' tulkitaan Pythonissa tyhjäksi? Onko tämä tietoturvaongelma? Tapahtuuko tässä niin, että GET-parametrina syötettyä tekstiä päätyy suoritettavaksi pythoniin, vai onko tämä tietoisesti valittu ominaisuus missä undefined kuuluu tulkita tyhjäksi?
Pekka Kasa