ardweaden / ethnoguessr-v2 Goto Github PK

Na repozitorij se ti je izmuznila mapa __pycache__, ki pa tja ne sodi, saj gre za avtomatsko generirane datoteke. Zato svetujem, da postaviš v repozitorij datoteko .gitignore (kar v vrhnjo mapo) - lahko kar uporabiš datoteko iz vzorca. Mapo __pycache__ pobriši iz repozitorija - z ustreznim .gitignore ti potem git več ne bo ponujal, da jo spet dodaš.

V zgornjem vzorcu je navedena tudi datoteka auth.py - vanjo lahko daš podatke za prijavo na bazo, ki tako ne bodo šli na repozitorij. Glede na to, da aplikacijo poganjaš na spletnem strežniku, lahko uporabiš svoje podatke za prijavo, ki so shranjeni samo na strežniku. Lahko se pa tudi povezuješ na bazo na fmf.uni-lj.si z uporabnikom javnost in geslom javnogeslo - v tem primeru bo seveda temu uporabniku treba dati ustrezne pravice (glej pdurcik/Baza-clanstva-RDR#3 za podrobnosti) - tako bo mogoče aplikacijo poganjati tudi lokalno (seveda za ceno tega, da bo javno dostopno geslo za neposredno branje iz baze in bo tako mogoče goljufanje).

Trenutno podatke vstavljaš v poizvedbe z metodo format, kar lahko vodi do napadov SQL injection. Namesto tega podatke podajaj v seznamu kot drugi argument metode execute - s knjižnico psycopg2 za delo s PostgreSQL bi to šlo npr. tako:

c.execute("INSERT INTO users (username, password, email, confirmed) VALUES (%s, %s, %s, %s)",
          [username, password, email, 0])

Tako se bodo podatki varno vstavili v poizvedbo glede na njihov tip. S knjižnico sqlite3 bi sicer namesto %s moral pisati ? na mestih, kamor naj se vključijo podatki.

Opozoril bi še na možnost goljufanja, ki se pojavi pri trenutni implementaciji. Trenutno namreč uporabniku poleg kazalca na sliko pošlješ še koordinate - že te bi lahko uporabnik prestregel. Pri reševanju pa potem izračun razdalje in točk opraviš v JavaScriptu, na strežnik pa pošlješ samo dosežene točke. Uporabnik bi torej lahko ponaredil tak zahtevek in si pripisal poljubno število točk.

Predlagam torej, da preverjanje rezultatov premakneš v strežniški del. Tako koordinat slike ne bi poslal uporabniku skupaj s sliko - bi si pa moral pri neskončnem načinu zapomniti, katero sliko je uporabnik nazadnje videl (na ER diagramu bi to pomenila relacija ena na več med uporabnikom in sliko, v bazi pa bi to bil dodaten stolpec pri uporabniku, ki je referenca na sliko). Pri izzivih pa to informacijo (glede na opis iz #1) že imaš. Pri reševanju bi torej uporabnik strežniku poslal koordinate - izračun razdalje in točk bi se tako opravil na strežniku, uporabnik pa bi dobil samo povratno informacijo.

Tvoj diagram ne prikazuje tistega, kar naj bi prikazoval ER diagram - izgleda mi bolj kot kak diagram poteka. Tudi vse entitete, ki jih imaš, niso potrebne - smiselno bi bilo ohraniti naslednje.

• Uporabnik - pri njem lahko hraniš tudi število iger in kumulativni rezultat (povprečni rezultat se pa lahko izračuna iz prejšnjih dveh, tako da ga ni potrebno hraniti v bazi).
• Slika - tukaj izgledajo v redu atributi.
• Izziv - to je v resnici tisto, kar imaš pod Vsi izzivi; zadostovalo bo, če imaš ID in ime (število krogov lahko dobiš tako, da prešteješ, koliko slik je povezanih z izzivom).

Ostale informacije naj bodo v relacijah.

• Slika sestavlja izziv: tukaj naj bo dodan atribut runda, ki pove, v katerem krogu se slika pojavi v izzivu.
• Uporabnik rešuje izziv: kolikor vidim, shranjuješ samo informacije o trenutnem stanju - zadostovalo bo torej, da imaš na tej relaciji atributa, ki povesta, koliko krogov je uporabnik že opravil pri tem izzivu, ter kakšen rezultat je dosegel do sedaj (ali je uporabnik končal izziv preveriš tako, da primerjaš število opravljenih krogov s številom vseh krogov). Če bi pa hotel hraniti informacije za vsak poskus, bi tukaj moral imeti relacijo med uporabnikom in zgornjo relacijo (slika sestavlja izziv).

Obe relaciji sta tipa več na več - na ER diagramu torej zanje ne narišeš puščic, v bazi pa bosta predstavljeni kot tabeli z ustreznimi relacijami na tabele entitet. Sicer pa, ko imaš na ER diagramu puščice (tj., omejitev tipa "največ enkrat v relaciji"), se jih vedno riše v smeri proti relaciji.

Tako ne potrebuješ posebej tabel z rezultati, saj jih lahko izpelješ iz ostalih tabel (morda bi pa koristil pogled z rezultati izzivov, ki ga izpelješ iz tabele zadnje relacije tako, da vzameš samo tiste vnose, kjer se število opravljenih krogov ujema s skupnim številom krogov). Posebej to pomeni tudi, da število tabel (in njihova struktura) ni odvisno od podatkov v bazi - tako ne boš potreboval novih tabel za vsak izziv.