ethnoguessr-v2's People
ethnoguessr-v2's Issues
.gitignore in dostop do baze
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).
Nevarne poizvedbe SQL in varnost aplikacije
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.
ER diagram in baza
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.
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.