Poglavje 2 LP Spletna aplikacija na strani odjemalca

LP

2.1 Pravila, zahteve in omejitve

Osrednji cilj vaj je pomoč pri razvoju lastnega projekta (LP), kjer boste na poljubno izbrani problemski domeni razvijali spletno aplikacijo od začetka do delujoče različice. Na vajah bodo potekale predvsem konzultacije glede razvoja lastnega projekta, zagovor lastnega projekta in prikaz uvodnih primerov ter orodij, ki jih boste uporabljali pri izdelavi lastnega projekta.

Opomba: Vsi udeleženci nadaljujete z delom na lastnem repozitoriju (LP-<vaš-GitHub-račun> v okviru organizacije UL-FRI-DevOps-WebDevelopment)!

LP Dinamična spletna aplikacija na strani odjemalca je sestavljen iz dveh delov, ki jih opravljate zaporedno v skladu s terminskem planu izvajanja tečaja:

• 1. del - uporabniški vmesnik, SPA in avtentikacija,
• 2. del - varnost in testiranje.

Povzetek funkcionalnih zahtev je prikazan na sliki 2.1, medtem ko so podrobnosti za vsak posamezen del lastnega projekta na voljo v nadaljevanju.

Slika 2.1: Povzetek funkcionalnih zahtev LP (večja slika)

Nalogo boste oddali v elektronski obliki preko elektronske pošte (povezava na zadnjo uveljavitev), sistema Github in povezave na delujočo aplikacijo.

Na zagovoru boste predstavili stanje v oddanem repozitoriju izvorne kode, kjer se bo upoštevalo stanje uveljavitve, ki je bila oddana preko elektronske pošte.

2.2 1. del Uporabniški vmesnik, SPA in avtentikacija

Navodila za 1. del

V tem delu naloge boste razvili spletno aplikacijo tako, da bo delovala kot ena sama spletna stran, ki se bo v celoti izvajala na strani odjemalca (tj. usmerjanje, pogledi in krmilniki). Vse vaše statične poglede, ki ste jih implementirali v obliki HTML predlog pri 1. delu naloge, pretvorite v Angular poglede v okviru komponent. Za dostop do podatkov iz podatkovne baze se bo uporabljal obstoječi REST API dostop, ki ste ga implementirali že pri 2. delu naloge.

Pri izdelavi vaše aplikacije uporabite ogrodje Angular, kjer podprete vse funkcionalnosti, ki ste jih opredelili v 1. delu naloge. Pri implementaciji vaše rešitve morate uporabiti naslednje gradnike:

• poleg osnovnega modula aplikacije uporabite še vsaj 1 dodatni modul, kjer boste implementirali usmerjanje,
• vsaj 3 transformacijske cevi, ki so smiselno vključene v aplikacijo,
• vsaj 3 razredi, ki so vsebinsko enakovredni dokumentom iz podatkovne baze MongoDB,
• vsaj 2 storitvi (dostop do lastnega REST API-ja in zunanje storitve),
• za vsak zaslon iz 1. dela naloge je na voljo vsaj 1 komponenta,
  • struktura Angular SPA aplikacije mora biti pripravljena z največjo možno mero ponovne uporabe komponent (tj. tisti deli, ki se na več straneh ponavljajo, jih implementirajte v obliki komponent in jih ponovno uporabite v ostalih komponentah),
  • s pomočjo komponent poskrbite za enotni izgled aplikacije tako, da ponovno uporabite komponente navigacije, glave, noge ipd.,
  • komponente naj bodo pri zasnovi neodvisne, ki jih pri uporabi prilagodite s prenašanjem podatkov med komponentami.

Validacija uporabniških vnosov

Poskrbite za validacijo morebitnih vnosov uporabnika na strani Angular aplikacije. Pri tem uporabite regularne izraze in s pomočjo JavaScript-a preprečite oddajo obrazca v primeru neuspešne validacije.

Npr. pri registraciji lahko preverite, če sta obe vtipkani gesli pravilni, preverite podatke o uporabniku, definirajte izbor možnosti iz zaprtega nabora možnih vrednosti ipd.

V datoteki README.md določite, kateri vnosi so dovoljeni za posamezna vnosna polja.

Navigacija

Spletne strani, na katerih navigacija v brskalnikih (sprehod naprej in nazaj v zgodovini) ne deluje, ne nudijo dobre uporabniške izkušnje. Poskrbite, da bo vaša Angular SPA aplikacija podpirala navigacijo v brskalniku, kljub temu da razvijate aplikacijo na eni strani.

Pomembno je, da lahko v vašo Angular SPA aplikacijo vstopite tudi s spletnim naslovom, ki ni začetni (npr. če se vaša Angular SPA aplikacija nahaja na spletnem naslovu / in zahtevate spletni naslov /racun/4509-1237, ki je del Angular SPA aplikacije, se mora ta funkcionalnost prikazati, ne da bi bili najprej preusmerjeni na začetno stran /).

Obvladovanje večje količine podatkov

Aplikacija naj omogoča pregledovanje večje količine podatkov za vsaj 1 zbirko dokumentov, kar pomeni upoštevanje naslednjih funkcionalnih zahtev:

• v primeru, da rezultat poizvedbe (npr. prikaz vseh objektov ali filtriran po določenem pogoju) vsebuje več kot 10 zadetkov, se seznam rezultatov prikaže po straneh (tj. 10 zadetkov na stran),
  • pri implementaciji si lahko pomagate z obstoječimi gradniki iz knjižnic (npr. Bootstrap, Angular Material, NGX Bootstrap, NG Bootstrap idr.),
  • na strani odjemalca vedno prikažete rezultate zgolj za 1. stran seznama, s klikom na naslednje strani pa izvedete novo REST API zahtevo na strežnik, ki vam vrne vse zadetke izbrane strani,
  • če je zadetkov 10 ali manj, gradnika Pagination ne prikažete,
• filtriranje prikazanih rezultatov se izvaja na strani strežnika v okviru REST API klica.

V okviru svojih podatkov morate zagotoviti, da zbirka dokumentov, kjer boste implementirali omenjeno funkcionalnost, vsebuje vsaj 30 dokumentov.

Dodatni gradniki grafičnega vmesnika

Ustvarite vsaj 1 pojavno okno, ki ga smiselno vključite v vašo aplikacijo in ga izvedite z uporabo komponente, kjer si lahko pomagate z že prej omenjenimi knjižnicami.

Poleg tega je potrebno vsa obstoječa pojavna okna vaše aplikacije implementirati z uporabo komponente za modalno pojavno okno.

V vaši aplikaciji naj bo prisotna tudi vsaj 1 vizualizacija podatkov v obliki grafa (uporabite lahko knjižnico NG2 Charts).

Avtentikacija in avtorizacija

Uporabite funkcionalnosti, ki ste jih že implementirali v 1. tečaju ter se osredotočite na to, da vaša aplikacija podpira vsaj naslednje 3 vrste uporabnikov:

• neprijavljen uporabnik oz. gost,
• prijavljen uporabnik,
  • navaden uporabnik in
  • uporabnik administrator.

V datoteki README.md opišite razlike med uporabniki (dostop/spreminjanja pogleda) predvsem z vidika funkcionalnosti, ki so jim na voljo.

Z uporabo žetona JWT implementirajte:

• prijavo uporabnikov (avtentikacija oz. preverjanje istovetnosti identitete) in
• nadzor dostopa (avtorizacija oz. pooblastitev) do določenih funkcionalnosti.

Popoln dostop do spreminjanja in brisanja podatkov v podatkovni bazi (preko REST API) naj ima uporabnik administrator, medtem ko omejene spremembe podatkov v podatkovni bazi (preko REST API) dovolite tudi prijavljenemu uporabniku. Neprijavljen uporabnik naj ima v skladu s funkcionalnostmi vaše aplikacije zgolj bralni dostop do izbranih funkcionalnosti.

Vaša aplikacija naj podpira registracijo novega uporabnika in prijavo obstoječega uporabnika v sistem. Ko se v sistem registrira nov uporabnik, ima dodeljeno vlogo navadnega prijavljenega uporabnika.

Ne pozabite na ustrezno šifrirano shranjevanje gesel v podatkovni bazi in dokumentiranje REST API metod zaradi vpeljave avtentikacije in avtorizacije ter podporo testiranju z JWT žetonom pri dokumentaciji REST API vmesnika.

2.3 2. del PWA, varnost in testiranje

Navodila za 2. del

Opomba: Vsa performančna in varnostna testiranja opravite na svojem razvojnem okolju, da ne boste po nepotrebnem porabili brezplačne vire v okviru gostovanja na Heroku in MongoDB Atlas.

Progresivna spletna aplikacija

S pomočjo orodja Lighthouse izvedite revizijo vaše spletne aplikacije iz vseh vidikov (učinkovitost, dostopnost, SEO, najboljše prakse in podpora PWA) ter za obe vrsti naprav (mobilna naprava in namizni računalnik).

V skladu s priporočili, ki vam jih vrne orodje Lighthouse, ustrezno dopolnite vaše aplikacijo. Če kakšnega vidika ne boste upoštevali, to argumentirajte v okviru README.md datoteke znotraj vašega repozitorija.

Še posebej se osredotočite na kategorijo PWA, kjer vašo aplikacijo pretvorite v progresivno spletno aplikacijo in uporabniku omogočite uporabo vaše aplikacije tudi v načinu brez povezave. Pri tem poskrbite za medpomnjenje tistih REST API klicev, za katere je to smiselno. Uporabniku naj bodo v načinu brez povezave na voljo vse funkcionalnosti vaše aplikacije, za katere je to možno doseči. Če se uporabnik nahaja v načinu brez povezave, potem na uporabniški vmesnik dodajte indikator stanja in poskrbite za alternativni uporabniški vmesnik oz. za skrivanje oz. onemogočanje funkcionalnosti, ki niso mogoče v načinu brez povezave.

Funkcionalni test

S pomočjo orodij Selenium, Mocha in Chai oz. ekvivalentnimi izvedite osnovne funkcionalne teste aplikacije.

Pri pripravi funkcionalnih testov upoštevajte naslednje:

• S testi naj bo podprt vsaj najbolj kompleksen osnovni scenarij uporabe prijavljenega uporabnika vaše aplikacije.
• V okviru testa naj bo prisotna povezava Selenium strežnika na produkcijsko verzijo vaše aplikacije.
• Preveriti je treba naslednje funkcionalnosti:
  • prijava uporabnika,
  • iskanje,
  • dodajanje in ažuriranje elementov aplikacije s strani prijavljenega uporabnika.
• Pri opredelitvi testa v ogrodju Mocha naj bodo uporabljeni naslednji gradniki:
  • vsaj \(\boldsymbol{5\ \times}\) describe,
  • vsaj \(\boldsymbol{5\ \times}\) context,
  • vsaj \(\boldsymbol{20\ \times}\) it,
• Test mora biti ponovljiv, kar pomeni, da pred/po test(om/u) uveljavite stanje po/pred izvedb(i/o) testa (npr. podobno je predstavljeno brisanje uporabnika in komentarja v okviru primera na predavanjih).
• Test naj bo na voljo v mapi /test, medtem ko se naj mochawesome poročilo zgenerira v mapo /test/porocilo.

Funkcionalni test se mora v celoti izvesti uspešno in ne sme vrniti napak.

Varnostni pregled

Z orodjem OWASP ZAP preverite osnovno varnost vaše aplikacije in v varnostni pregled vključite naslednje vire:

• OpenAPI specifikacijo REST API strežnika preko uvoza swagger.json datoteke,
• seznam ključnih spletnih povezav vaše aplikacije, ki jih uvozite iz datoteke,
• rezultat ročnega preiskovanja vaše aplikacije v načinu HUD, kjer preverite vse funkcionalnosti (tj. prijava, registracija, prehod med vsemi stranmi, dodajanje, ažuriranje in brisanje virov).

Nato nad vašo aplikacijo izvedite pregled s Spider in Ajax Spider, na koncu pa še aktivni napad z Attack.

V skladu z ugotovljenimi pomanjkljivostmi varnostno popravite vašo aplikacijo tako, da OWASP ZAP identificira zgolj še modra opozorila (angl. Informational Priority Alerts).

Opomba: Pogojno so lahko prisotna še ostala opozorila, če gre po vašem mnenju za napačno identificrane napake, ki jih morate nato argumentirati v okviru datoteke README.md.

Poročilo varnostnega testiranja oddajte v repozitorij v mapo /test/security, kjer morajo biti prisotne naslednje datoteke:

• datoteka s seznamom ključnih spletnih povezav vaše aplikacije (vsaka povezava je v svoji vrstici),
• 2x HTML poročili varnostnega pregleda (Report → Generate HTML Report …) pred varnostnimi popravki in po izvedenih varnostnih popravkih.