Potrebne smernice, PHP MySQL "API"

• 0Niko još nije pohvalio poruku.
  Registruj se da bi pohvalio/la poruku!

Prvi put radim ovako nešto pa ne bih da upadnem u zamku i da napravim neki propust.
Molim za smernice.

Situacija :
Xamarin.Forms aplikacija za Android i iOS koja zahteva online bazu podataka.
Koristiće je do 30 ljudi i svi će moći da upisuju podatke u bazu i da čitaju podatke iz baze.

Koliko sam shvatio, Xamarin.Forms nema način da se poveže na bazu direktno.
Zbog toga sam primoran da koristim php skriptu na svom sajtu koja se na drugom hostu povezuje sa bazom i vrši interakcije.

Moje rešenje na kom trenutno radim :


PHP Skripta preko URL parametara izvršava predefinisane funkcije za upisivanje i čitanje iz baze.
Skripti iz aplikacije pristupam samo preko URL-a i šaljem podatke.
Ne šaljem query skripti, već su funkcije hardkodirane da upišu nove unose u bazu koje pokupe iz parametara.


Tako da skripta i aplikacija uvek budu prekonfigurisane da šalju podatke na način koji druga strana očekuje i u slučaju da nije tako, ništa se ne dešava.

Da li je to generalno OK?

Šta bi se dogodilo u slučaju da neko pošalje zlonamerni query ili nešto slično a skripta iskoristi INSERT da taj string ubaci u Table?

Aplikacija će prvobitno biti u upotrebi u zatvorenom krugu tako da ništa nije u planu za javnu objavu pa me bezbednost pristupa ne brine, ali sam planirao za početak da imam lozinku koju će aplikacija slati skripti a skripta proveravati istu i kod izvršiti samo ako se lozinka poklapa.

Osim toga, ono što me takođe interesuje oko same MySQL baze je :

Treba da sačuvam grupisane podatke.

Na primer, u sklopu jedne liste, danas neko napravi 10 novih unosa i treba da ih sačuva u bazu.

Da li je OK da u aplikaciji generišem unikatni ID i da te unose ubacujem u bazu pojedinačno a da ih kasnije pokupim tako što ću grupisati sve podatke iz baze koji imaju isti ID ?

+ Primer

ID = 1
Data1 = Pera
Data2 = Perić

ID = 1
Data1 = Žika
Data2 = Žikić

To pošaljem pojedinačno kao unose u Table i kasnije povučem sve unose iz baze koji imaju isti ID i dobijem podatke grupisane.

Hvala

• 1Ovo se svidja korisniku: Srki94
  
  Registruj se da bi pohvalio/la poruku!

Napisano: 11 Nov 2021 8:42

Podatke za upis ubazu salji preko POST metode, ne preko GET. Ako saljes podatke preko url-a, svako moze da pozalje sta hoce, a mislim i da si ogranicen maksimalnom duzinom stringa.

U php skripti podacima pristupas preko $_POST supeglobalne promenjive.

Sto se tice upisa u bazu, koristi PDO i prepared statements da bi sprecio SQL injection, primer:
[Link mogu videti samo ulogovani korisnici]

Za samu bazu nisam sigran da li je to ok nacin da upisujes podatke, nisi dao dovoljno detalja. Ako ces imati samo jednu tabelu i nemas potrebu da vremenom prosirujes bazu, verovatno je ok, ali napisi detaljnije pa da vidimo
zasto ne bi imato tabelu:
id  ime  prezime  data1  data 2 ...


Dopuna: 11 Nov 2021 8:44

I ovo mi se cini interesantno:
[Link mogu videti samo ulogovani korisnici]

• 0Niko još nije pohvalio poruku.
  Registruj se da bi pohvalio/la poruku!

Hvala Đole;

Mislim da bi jedna tabela pokrila sve moje potrebe.

Biće tri grupe korisnika. Korisnici mogu da vide podatke koje je unela njihova grupa, ne druge grupe.

Postoje dve vrste podataka koji se upisuju u bazu - Jedina razlika između te dve vrste je jedna kolona. Ostale kolone obe vrste podataka dele.

Tako da u suštini mogu da imam jednu tabelu sa svim unosima koji mi trebaju da sortiram vraćanje podataka.

Tabela :

IDGrupeKorisnika
IDKategorije
InternaŠifra
Stanje
DatumUpisa
IDKorisnika
Datum

I onda iz te jedne tabele vraćam podatke u zavisnosti od onoga ko koristi aplikaciju.

Grupa 3 želi da vidi sve podatke iz kategorije br2 :

Vratim sve stavke gde je IDGrupeKorisnika 3 a IDKategorije 2.


S tim, što - kao što rekoh, tokom jednog upisivanja u bazu neko koristi aplikaciju za desetine unosa i hteo bih da ih grupišem u jednu celinu. Tako da na kraju umesto 10 pojedinačnih unosa imam fiktivnu grupu zarad lakšeg snalaženja i pregleda.

"Hej, korisnik taj i taj je tog i tog datuma dodao 10 unosa u bazu, klikni da vidiš unose."

To bih rešio tako što bih dodao još jednu kolonu - unikatni ID koji bi generisala sama aplikacija i onda bih mogao, kad povučem sve podatke iz baze, da prema tom unikatnom ID-u grupišem podatke za prezentaciju.


Sa druge strane, za svaki unos u bazu na ovaj način moram da upišem ID grupe ID Tipa podataka itd. Ne znam koliko je to "lošije" od postojanja posebnih tabela za svaku grupu, gde bi se u kodu odmah povlačili podaci iz te odgovarajuće tabele?


Što se tiče PHP-a, baciću pogled na ovo što si poslao da vidim da skrpim nešto.

• 3Ovo se svidja korisnicima: vasa.93, _Sale, Srki94
  
  Registruj se da bi pohvalio/la poruku!

Napisano: 12 Nov 2021 9:54

Srki94 ::Aplikacija će prvobitno biti u upotrebi u zatvorenom krugu tako da ništa nije u planu za javnu objavu pa me bezbednost pristupa ne brine, ali sam planirao za početak da imam lozinku koju će aplikacija slati skripti a skripta proveravati istu i kod izvršiti samo ako se lozinka poklapa.

Sve sto je na internetu je javno. To sto trenutno samo ti i jos 30 ljudi znate URL ne znaci da ce tako i da ostane. Nece. Botovi, spideri, crawl-eri postoje i cesljaju internet non stop. Ovo zapamti i primenjuj na sve sto radis.

Drugo, samo lozinka je znacajno slabija zastita od korisnickog imena i lozinke zajedno. Primera radi, ako imas lozinku od samo 6 slova i brojeva, broj mogucih kombinacija je 62^6, a korisnicko ime i lozinka imaju 62^6 * 62^6, odnosno 62^12 mogucih kombinacija, sto je 56.800.235.584 PUTA vise kombinacija.

Trece, i ne manje bitno, bilo kakvi podaci za pristup (bilo samo lozinka, bilo korisnicko ime + lozinka) koji su vec upisani u aplikaciju i kao takvi nepromenjivi je za nijansu bolja zastita nego da ih nemas uopste. Skinem apk, provucem kroz neki dekompajler, i u 99% slucajeva cu moci da ih vidim.

Cetvrto, i jos uvek vrlo bitno - sva komunikacija izmedju aplikacije i servera mora da ide kroz HTTPS. U suprotnom su svi podaci koje saljes u obliku obicnog teksta, i kao takvi dostupni MITM napadu. Imas sad besplatne Let's Encrypt sertifikate i prosto je glupo da to ne iskoristis.

Peto, i ne najmanje bitno - SVE sto stigne iz aplikacije moras da tretiras sa nepoverenjem i da proveris pre nego sto prosledis funkciji koja radi bilo sta sa bazom. NIKAD, ali NIKAD, ne veruj necemu sto je uneo korisnik.



To je sto se tice sigurnosti. Sto se tice arhitekture baze, sacekaj da popijem kafu, pa cu i to da pogledam.

Dopuna: 12 Nov 2021 13:53

Dalje, struktura baze. Struktura baze, kao i sam kod, trebalo bi da budu na engleskom, osim ako nisi 100% siguran da nikad niko ko ne razume jezik kojim si pisao nece raditi na tom kodu/bazi. Ja sam radio sa bazama na italijanskom, holandskom i nemackom, i sve vreme je originalni developer stucao koliko sam spominjao njega i njegovu familiju.

Prvo, svaka tabela mora da ima primary key koji ima auto increment property. U suprotnom neces ni iz phpMyAdmin (ili nekog slicnog alata) moci preko GUI-a da obrises/izmenis ijedan rekord, moraces svaki put da pises query rucno.

Drugo, svaki put kad tabela referencira drugu, prvo navodis koju tabelu a onda i koju kolonu. To znaci da se kolona u bazi ne zove IDKategorije nego KategorijaID - odnosno, CategoryID.

Trece, nema sanse da ti jedna tabela zavrsi posao a da ne bude busno. Sa jednom tabelom, i primerom koji si okacio - baza nema ama bas nikakvu ideju koji je ID grupe korisnika. Sto znaci da taj uslov dolazi iz aplikacije, a ako dolazi iz aplikacije - moze da se lazira. U stvari, ne treba mi ni aplikacija, mogao bih iz Postman-a da procitam sve upise ikad obicnom manipulacijom parametara koji salje "aplikacija". Sve sto moze da vidi tvoja aplikacija mogu i sve ostale aplikacije ako posalju adekvatan request. I nikakav kod unutar tvoje aplikacije ne igra ama bas nikakvu ulogu, jer ako ja mogu (a mogu) da napravim identican request van aplikacije, mogu i da se igram sa njim.

Validacija na front-endu/aplikaciji sluzi da ne nerviras korisnika (i nicemu vise), validacija na back-endu sluzi da proveris podatke.

Razlicite tabele za razlicite grupe nije dobra praksa, jer em nista ne dobijas po pitanju sigurnosti, nego ti i otezava pregled korisniku sa visim/maksimalnim privilegijama. Hoces da vidis sve unose za juce, iz svih grupa? Tri upita ka bazi, u tri odvojena pregleda, ili UNION upit da ti sva tri prikaze u istom pregledu? Plus, sad imas 3 grupe, sto povlaci i tri potpuno iste tabele, sta ces da radis kad budes imao 17 grupa? Sedamnaest potpuno istih tabela?

• 0Niko još nije pohvalio poruku.
  Registruj se da bi pohvalio/la poruku!

Vau Rastaman, hvala na iscrpnom odgovoru.

Većinu spomenutih stvari sam već ispoštovao ili planirao, na ovaj ili onaj način.

- Znam da može da se izvuče hardkodirana lozinka, ne znam šta bih mogao da uradim po tom pitanju za sada

Razmišljao sam da za svakog korisnika aplikacije ručno unesem enkriptovane login podatke u bazu. Loguju se preko aplikacije, ako je login uspešan, vratim im token koji mogu da koriste ubuduće ?
Realno, opet taj token može da se iskopa... Stvarno nemam predstavu za sada kako to da rešim.

Imam https, ostalo mi je samo da rešim problem sa Androidom u vezi POST-a, ne radi trenutno sa https linkom iz nekog razloga. Nisam stigao da istražim zašto ali svakako planiram da koristim https.

- Znam da ne treba da verujem korisnicima, otud i pitanje šta bi se desilo da proslede query

Svakako sam planirao da odradim provere u samoj php skripti, ali tražim trenutno dobru praksu za to.

- Struktura baze jeste na Engleskom, u postu je samo primer na srpskom zbog jasnoće
- Imam primarni ključ u bazi, isto upozorenje mi je dao phpmyAdmin pa sam ubacio ključ
- Za ID naziva kolona nisam znao ali je opet stvar do srpskog jezika u postu. Iz dosadašnje prakse mi je nekako logično da ID ide na kraju, tako da su mi svi nazivi kolona koji sadrže "ID" takvi u bazi

Citat:Trece, nema sanse da ti jedna tabela zavrsi posao a da ne bude busno. Sa jednom tabelom, i primerom koji si okacio - baza nema ama bas nikakvu ideju koji je ID grupe korisnika. Sto znaci da taj uslov dolazi iz aplikacije, a ako dolazi iz aplikacije - moze da se lazira. U stvari, ne treba mi ni aplikacija, mogao bih iz Postman-a da procitam sve upise ikad obicnom manipulacijom parametara koji salje "aplikacija". Sve sto moze da vidi tvoja aplikacija mogu i sve ostale aplikacije ako posalju adekvatan request. I nikakav kod unutar tvoje aplikacije ne igra ama bas nikakvu ulogu, jer ako ja mogu (a mogu) da napravim identican request van aplikacije, mogu i da se igram sa njim.

Da, dolazi iz aplikacije kad se upisuju podaci i aplikacija ga proverava kad povuče podatke. Nažalost, nisam uspeo da nađem resurse za dobru praksu pravljenja MySQL baze... tako da sam i tu u mraku u potpunosti.

Citat:Razlicite tabele za razlicite grupe nije dobra praksa, jer em nista ne dobijas po pitanju sigurnosti, nego ti i otezava pregled korisniku sa visim/maksimalnim privilegijama.

Nisam razmišljao na taj način o tome. Dakle, tri tabele za grupu su loša ideja, jedna tabela bez drugih tabela je isto loša ideja. Šta mi je činiti onda?

Ako imaš neki resurs koji bih mogao da proučim, u vezi sa pravljenjem same baze, dobrom praksom ili vezano za ove stavke koje mi nisu jasne - prosledi, molim te.

Ja ću za sada primeniti koliko mogu sve ovo što ste napisali i nastaviću da radim sa jednom tabelom, da ne zaustavljam razvoj aplikacije ... pa ću blagovremeno da poboljšavam dalje.

Već sada je struktura dosta drugačija nego pre otvaranja ove teme, tako da mi je drago što delite savete

• 0Niko još nije pohvalio poruku.
  Registruj se da bi pohvalio/la poruku!

Srki94 ::Razmišljao sam da za svakog korisnika aplikacije ručno unesem enkriptovane login podatke u bazu. Loguju se preko aplikacije, ako je login uspešan, vratim im token koji mogu da koriste ubuduće ?
Realno, opet taj token može da se iskopa... Stvarno nemam predstavu za sada kako to da rešim.

Prvo, sve sto se enkriptuje, moze i da se dekriptuje. Trud i vreme se razlikuju, ali moze. Tebi treba hash - jednostrana enkripcija - da ne moze da se dekriptuje (ili makar ne bez brute force/collision napada u normalnom vremenu). Pogledaj SHA1 i to uz salt.

Drugo, moze, ali isto tako token moze da ima vreme kad istice. Tipa X minuta od poslednje interakcije. Tako dolazis do situacije da, cak iako neko nekako dohvati token, on je najverovatnije istekao i samim tim nevalidan. Izguglaj "JWT" da vidis kako je to elegantno reseno.

Srki94 ::Imam https, ostalo mi je samo da rešim problem sa Androidom u vezi POST-a, ne radi trenutno sa https linkom iz nekog razloga. Nisam stigao da istražim zašto ali svakako planiram da koristim https.

No https, no party. Nema dalje.

Srki94 ::- Znam da ne treba da verujem korisnicima, otud i pitanje šta bi se desilo da proslede query

Ne da ne treba, nego ne smes. Programiranje danas je trka izmedju softverskih inzenjera koji pokusavaju da naprave vece i bolje programe otporne na idiote, i Univerzuma koji pokusava da napravi vece i bolje idiote. Trenutno, Univerzum pobedjuje¹. A imas i maliciozne "korisnike". Plus "little Bobby Tables" iz prethodnog posta.

Srki94 ::Da, dolazi iz aplikacije kad se upisuju podaci i aplikacija ga proverava kad povuče podatke. Nažalost, nisam uspeo da nađem resurse za dobru praksu pravljenja MySQL baze... tako da sam i tu u mraku u potpunosti.

Opet, recimo da imas neki vid autentifikacije korisnika. On kaze ko je, a ti proveravas u back-endu sta sme da radi. Sto ukljucuje kojoj grupi pripada, i koji query smes da opalis. Front-end sluzi za prikaz i olaksavanje koriscenja onom ko mu pristupa. Sve provere su na back-endu.

Zamisli da imas uredjaj koja ocitava otisak prsta, proverava i ako je ok salje elektricni impuls bravi da se otkljuca. To zvuci super cool u teoriji, a sta te sprecava (u praksi) da izbacis uredjaj tako sto jednostavno iseces kablove ka njemu, prespojis, stavis svoj i pustis impuls ka bravi da se otkljuca?

Korisnik sme da pristupi samo delu koji CITA parametre za pristup, onaj deo koji ih proverava i otkljucava mora da ostane VAN dohvata korisnika zauvek. U primeru sa bravom iz prethodnog pasusa - citac otiska je van prostorija, ali on samo CITA otisak i prosledjuje sta je procitao kontrolnom delu koji je UNUTAR prostorije. Kontrolni deo onda odlucuje da li da otvori vrata ili ne, ali ti svakako ne mozes da dodjes do njega bez da udjes.

Srki94 ::Nisam razmišljao na taj način o tome. Dakle, tri tabele za grupu su loša ideja, jedna tabela bez drugih tabela je isto loša ideja. Šta mi je činiti onda?

Imas 3 tabele. Jednu za upise, manje vise kako si je zamislio. Druga je za grupe, treca je za korisnike. Sve povezane medjusobno. Ako korisnik moze da bude u vise grupa, onda imas i cetvrtu tabelu (many-many) koja nosi informaciju kojim grupama pripada koji korisnik.

• 0Niko još nije pohvalio poruku.
  Registruj se da bi pohvalio/la poruku!

Xamarin slicno radi kao i java android. Ja kad moram da android app povezem na mysql PHP-a pravim api koji mi vraca json. Konektuje se pomocu webservice i obavezno ASYNC taskove. Sto se tice php-a klasicno putem GET metode vrtis ako je url sadrzi neki param pozovi neku funkciju koja vraca rezultate ali u json-u. Slicno nesto kao front-controller! U C# onda se konektuj na webserver ili se direktno povezuj na URL ali ti @rasta gore vec napomenuo da to nije bas sigurono.
Prvo napravi metode da ti vracaju rezultate iz baze pa onda webserver api a nakon toga peglaj c#. Prsto je