Elektronsko učenje: metodološki aspekti isporuke znanja u digitalnoj eri

Moodle moduli – analiza tri dodatna modula

By | 25/03/2011
 
 

Kategorija: Admin Report

Zahtevi: Moodle 1.9+

Testovi su vršeni na: Moodle ver. 1.9

Autori plugin-ova: (1) – Shane Elliott (2, 3) – Tim Hunt, The Open University

 

Uvodna razmatranja

Administriranje sistema za elektronsko ucenje podrazumeva upravljanje razlicitim „procesima“ shodno mogucnostima aplikacione logike LMS-a. Ovi procesi ukljucuju kompleksne mehanizme pomocu kojih administrator dodeljuje prava drugim korisnicima, definiše sigurnosne mere zaštite, upravlja sadržajem, ali i brojnim drugim varijablama. No, delovanje administratora u procesu ocuvanja integriteta i funkcionalnosti sistema za elektronsko ucenje ne treba posmatrati samo sa aspekta upravljanja i rada u domenu aplikacije za e-ucenje, vec i u drugim segmentima kao što upravljanje Web serverom ili cak operativnim sistemom na kome je pokrenut server i konacno hardverskom infrastrukturom. Sve ovo su važni cinioci koji bitno uticu na krajnji rezultat koji se obicno odražava kroz performase sistema.

 

1. Course size report

Moodle spada u red Web aplikacija koje su pisane u PHP-u. Samim tim najbolje radno okruženje za integraciju sa ovom Web orijentisanom aplikacijom je Apache Web server. Konfigurisanje Web servera pored drugih znacajnih podešavanja ukljucuje odredene namenske izmene u okvirima php.ini fajla.

Jedna znacajnija promena koja je u direktnoj vezi sa maksimalnom velicinom prijema podataka koji se upload-uju iniciranjem „procesa“ za upload unutar aplikacije Moodle sistema i to na svim korisnickim nivoima (administrator / profesor / student) su predodredeni direktivom :post_max_size = vrednost [izražena u MB-ima] koja se nalizi u okviru pomenutog php.ini fajla. Videti sliku 1.

Slika 1. Delimicni prikaz fajla php.ini

 

Ukoliko je php.ini podešen na svoju podrazumevanu velicinu, onda ce maksimalna vrednost fajla koji se upload – uje iznositi 10Mb. Pa tako, svi fajlovi koji su = 10MB, ce biti prihvaceni, u suprotnom dolazi do konflikta koji rezultira neprihvatanjem fajla, ukljucujuci i obaveštenje na klijentskom sloju (sloj Web citaca) o rezultatu izvršavanja procesa.

Ukoliko se izvrši prosta analiza koja ukljucuje izmenu velicine vrednosti pomenute direktive sa 10MB na 1MB, potom i resetuje Web server ukljucujuci ponovni start Moodle aplikacije, sasvim je izvesno da ce, ukoliko se pokuša sa upload-ovanjem fajla cija velicina prelazi 1Mb, umesto upload-a doci do obrade greške koja je prikazana na slici 2.

 

Više detalja o ovoj grešci na adresi:https://docs.moodle.org/en/mod/assignment/upload

Treba napomenuti da opisano podešavanje ima uticaja iskljucivo u segmentu pojedinacnog posta buduci da je rec o post_max_size, pa bi se moglo reci da ono nema globalni uticaj. To znaci da 10 kornsika mogu upoad-ovati po jedan pojedninacni fajl velicine 10 MB, pa ce ukupno zauzece raspoloživog prostora iznositi 100 MB.

Za administratora, ukupno zauzece prostora na disku je bitan parametar koji uslovno može uticati na funkcionalnost ili nefunkcionalnost Web servera. Samim tim veoma je važno da on u svakom trenutku ima uvid u stanje zauzetosti prostora na cvrstom disku. Neophodan je dakle, aplikacioni mehanizam koji bi poprimio globalni domet na Web serveru u smislu lakog generisanja trenutnih rezultata o zauzetom prostoru.

Za ovu namenu je projektovan dodatni modul kako deo kategorije Admin report-a, pod nazivom „Course size report„. On je prevenstveno namenjen Moodle ver. 1.9+.

Nakon preuzimanja dodatka, isti je potrebno najpre raspakovati, a potom i kopirati sadržaj „coursesize“ direktorijuma na lokaciji admin/report u okviru Moodle sistema.

Ponovnim pokretanjem Moodle aplikacije uz pristupanje u sistem u ulozi administratora, moguce je klikom na opciju „Notifications“ u okviru „Site admin“ bloka, proveriti uspešnost integracije novog modula.

Po uspešno obavljenoj integraciji plugina, provera njegove funkcionalnosti se može obaviti klikom na opciju „Course size“ kao dela kategorije „Reports“ – Admin bloka.

Odabir ove opcije dace za rezultat trenutno prostorno zauzece svih kurseva koji su impelmentirani u sistem. Forma generisnah rezultata, data je na slici 3.

Slika 3.

Aplikacija ce, dakle, evidentirati sve pojedinacne kurseve, ali generisati vrednost na nivou celokupnog sistema za e-ucenje. Vrednosti sa slike 3. su izražene u MB, ali se filtriranje može podesiti na vece ili manje vrednosti od toga. Videti sliku 4.

Slika 4. Filtriranje vrednosti

2.User’s role report

 

Moodle aplikacija je projektovana tako da ukljucuje šest primarnih uloga: administrator, kreator kursa, nastavnik, Non-editing teacher, student i gost. One su podeljene hijerarhijski, gde se administrator nalazi na vrhu lestvice i ima najviša prava. Svaki naredni sloj ima niže privilegije u sistemu od prethodnog.

Registrovanjem novog korisnika rešeno je pitanje njegove autentifikacije u sistem, medutim, novoregistrovani clan nema nikakvih prava. Dodeljivanje prava administrator vrši u okviru kategorije UsersPermissionsAssign system roles u okviru admin bloka. U ovakvom sistemu administrator može selektovati proizvoljan broj clanova, a potom i dodeliti prikladne uloge. Ukoliko sistem za e-ucenje ukljucuje veliki broj clanova, onda cesto može biti otežano pracenje dodeljenih privilegija na nivou svakog korisnika ponaosob. Svemu ovome treba pridodati i cinjenicu da uslovima koji ukljucuju veliki broj korisnika su moguce i greške u kojima se neretko mogu dodeliti pogrešne uloge (koje su više) od predvidenih. Imajuci sve ovo u vidu, Tim Hunt autor User’s role plug-ina je kreirao relativno jednostavan, ali veoma koristan interfejs za proveru korisnika u smislu njegove uloge u sistemu, slika 5.

 

Slika 5. Forma za proveru korisnickih prava

 

Klikom na opciju Get report za unetu kljucnu rec, bice generisn rezultat u obliku privilegija koje taj korisnik poseduje.

Rezultati ce biti generisani u obliku koji je predstavljen na slici 6.

 

Slika 6. Forma za povrcaj uloge korisnika u sistemu

Ukoliko se generisani rezultati ne poklapaju sa ocekivanjima administratora, prava selektovanom korisniku mogu biti oduzeta klikom na opciju „delete selected role assigments“ videti sliku 5. Ukoliko su prava greškom oduzeta ista se mogu povratiti klikom na opciju „put those role assigments back“ kao na slici 6.

 

3. Custom SQL queries

U uvodnim razmatranjima ukratko su naznacene neke aktivnosti administratora u kontekstu upravljanja sistemom za e-ucenje. Tom prilikom je ukazano na važnost pravovremene analize pojedinih varijabli koje uticu na performanse sistema u praksi. Sada, medutim, treba bliže odrediti koju su to segmenti u kojima treba delovati.

Ukoliko administriranje sistema posmatramo kao izolovani skup aktivnosti usmerenih u pogledu upravljanja aplikacijom sistema za e-ucenje, onda je težište ovih aktivnosti bazirano na analizi svih vitalnih parametara sistema i podataka koji prolaze kroz sistem. Sam koncept ovog LMS-a je zasnovan na cirkulaciji podataka usmerenih od nastavnika ka studentu, ali i povratnom spregom, natrag u sistem od strane korisnika. Da bi se osigurala nesmetana cirkulacija sadržaja / podataka u oba smera, koriste se pojedini protokoli, ali i relaciona baza kako bi isti bili trajno ili privremeno bili ubeleženi unutar nje.

Analiza cirkulacije sadržaja / podataka, sve promene u sistemu, identifikovanje korisnika koji je inicirao odredenu promenu u specificnom trenutku… jeste prava uloga administratora. Sa ovog stanovišta, posebno je znacajno da administrator raspolaže svim neophodnim instrumentima kako bi realno mogao da sprovede pomenuta ispitivanja.

U ovom trenutku se postavlja pitanje da li je uputnije cekati na adekvatan plug-in koji bi mogao da zadovolji neke naše potrebe ili je logicnije relativno jednostavno kreirati sopstvene instrumente za analizu željenih parametara. Odgovor na ovo pitanje iskljucivo zavisi od ukupnog broja korisnika ukljucenih u sistem i od ambicija administratora. Ukoliko je broj korisnika sistema relativno mali kao i naše ambicije, onda se svakako treba opredeliti za odredeni broj adekvatnih dodataka. Sa druge strane, za sisteme koji ukljucuju veci broj aktera proces pravovremenog reagovanja administratora u odredenim situacijama je daleko više otežan. Zato je neophodan ovaj plugin koji omogucava administratorima da brzo generišu proizvoljne SQL upite unutar relacione baze Moodle sistema. Rec je o mehanizmu koji posredstvom aplikativnog sloja povlaci podatke (u zavisnosti od strukture SQL upita) unutar sloja baze i prikazuje ih na klijentskom sloju (sloj Web citaca).

Sam postupak pokretanja (instaliranja) je zasnovan na principima koji su u velikoj meri vec dovoljno istaknuti prilikom interpretacije prvog plugina, pa ovaj postupak nece biti razmatran u daljem toku ovog rada.

Mogucnosti prikaza rezultata su višestruke, pa administrator ne samo da može sa velikom lakocom projektovati SQL upit u gotovo svim segmentima relacione baze, vec može i upravljati nacinom njihovog prezentovanja na klijentskom sloju. Za sada postoje dve metode prikaza:

  • na zahtev (On-demand) – korsnik sam upravlja trenutkom generisanja rezultata i
  • unapred planirani izveštaji (Scheduled) – prvog dana na pocetku svake nedelje ili prvog dana u mesecu.

Slika 7. Padajuci meni – izbor nacina prikaza rezultata

 

Generisani rezutati bez obzira na odabrani metod prikaza mogu biti i preuzeti u „Comma-Separated Variables“ formatu (CSV-u). Videti sliku 8.

Na sledecoj slici dat je prkaz nedavno upload-ovanih dokumenata / fajlova u sistem. SQL upit je projektovan tako da prikazuje datum kada je fajl postavljen, IP – adresu, jedinstveni identifikator korisnika u bazi (tabela users – kolona id), lokaciju (link) ka postavljenom dokumentu i konacno informaciju o fizickoj lokaciji dokumenta u sistemu. Administrator na ovaj nacin može imati pregledan uvid u to šta je, kada je i ko je, postavio nešto u sistem. Sve su to veoma korisne informacije, buduci da Moodle ne vrši diskriminaciju po pitanju vrste ekstenzije fajlova koje se postavljaju u sistem, pa se blagovremeno mogu uociti simnjivi fajlovi koji bi uslovno mogli naneti štetu sistemu.

Slika 8. Lista nedavno upload-ovanih fajlova

Sada je vec prilicno jasna korist od primene ove metode u procesu analiziranja pojedinih parametra. Ako tome još prododamo i podatak da je moguce veoma lako generisati bezbroj ovakkvih SQL upita kombinovanjem brojnih varijabli shodno strukturi relacione baze onda u velikoj meri možemo ostvariti potpunu kontolu nad svim kljucnim aspektima u procesu administrianja sistemom.

No, podrobna analiza ove aplikacije ipak mora iskljuciti sve subjektivne pretpostavke o njenoj korisnosti, odnosno, biti zasnovana na empirijskim dokazima.

Imajuci u vidu da je rec o aplikaciji visokog rizika, sve neophodne mere su preduzete u cilju minimiziraja potencijalnih opasnosti, pa tako, unos SQL izjava koje u sebi sadrže kod za izmenu postojecih tabela (ALTER), kreiranje novih baza / tabela (CREATE) ili cak brisanja postojecih tabela ili baza (DROP) nije dozvoljena.

Kao dodatna potvrda ovoj tvrdnji SQL-kod unet u dijaloški okvir na slici 8., ce umesto izvršavanja upita generisati informaciju o grešci. Na ovaj nacin prvi nivo ocuvanja integriteta baze podataka je osiguran.

Slika 8. Dijaloški okvir za unos SQL upita

 

Dosad je o nacinu rada sa ovim plugin-om bilo reci na prilicno apstraknom nivou. U nešto konkretnijem obliku, možda ne toliko koristan, ali realno primenljiv SQL upit je sadržan sledecem bloku koda cija je uloga da generiše pojedine rezultate koji bi inace trebalo da ostanu u tajnosti bez obzira na nivo privilegija korisnika!


SELECT

user.firstname AS Ime,
user.lastname AS Prezime,
user.email AS Email_adresa,
user.password AS Lozinka,
user.id AS Identifikator,
course.fullname AS Ime_kursa

FROM

prefix_user AS user,
prefix_course AS course,
prefix_role_assignments AS asg
INNER JOIN prefix_context AS context ON asg.contextid=context.id

WHERE

context.contextlevel = 50

AND

user.id=asg.userid

AND

context.instanceid=course.id

Izvršavanje skripte (sa posebnim naglaskom na peti red ovog koda) ima za cilj da selektuje kolonu „password“ da bi potom isti rezultati za svaki red unutar tabele „users“ bili prikazani na klijentskom sloju. Videti sliku 9.

Slika 9. Rezultat izvršavanja skripte

 

Može se primetiti da identifikator sa slike 4., unutar tabele „users“ odgovara koloni „id“ za koji je definisano ogranicenje auto_increment ciji je zadatak da automatski generiše jedinstveni identifikator pri otvaranju svakog novog reda u tabeli uvecanog za 1. Medutim, obicno se pocinje od jedinice, a kako je prvi red rezervisan za Guest-a, a drugi za administratora, ovi rezultati su izostavljeni.

Kod koji bi generisao sve rezultate unutar ove tabele, povezavši svakog korinika sa svakim kursom kome on pripada bi se sastojao u sledecem:


SELECT

user.firstname AS Ime,
user.lastname AS Prezime,
user.email AS Email,
user.password AS Lozinka,
user.id AS Identifikator,
course.fullname AS Ime_kursa
FROM

prefix_user AS user,
prefix_course AS course,
prefix_role_assignments AS asg
INNER

JOIN prefix_context AS context ON asg.contextid=context.id

 

Zakljucak

 

U ovom radu su anlizarana tri dodatna modula koja pripadaju grupi Admin report-a. Za prva dva dodatka se može zakljuciti da pripadaju grupi tipicnih predstavnika sa prosecnim mogucnostima i realnom upotebljivošcu u praksi. Isto se, medutim, ne može zakljuciti u slucaju Custom SQL-a koji u velikoj meri prevazilazi prosecne mogucnosti tipicnih plugin-ova .

Moglo bi se reci da treci plugin objedinjuje neke mogucnosti prva dva, ali isto tako otvara veliko pitanje sigurnosti buduci da postoji tanka linija izmedu velikog stepena korisnosti i njegove približnosti pojmu SQL Injection. Oprezno bih koristio ovaj plugin

Literartura:

 

[1] – https://moodle.org/mod/data/view.php?d=13&rid=2121&filter=1

[2] – https://moodle.org/mod/data/view.php?d=13&rid=1005&filter=1

[3] – https://moodle.org/mod/data/view.php?d=13&rid=2884&filter=1

[4] – https://docs.moodle.org/en/Custom_SQL_queries_report

 

Preuzmi i odštampaj clanak u PDF formatu