Cześć,

Jest sobie formularz wyświetlający select oraz inputy, zależne od wartości wybranej w select - realizuje to skrypt javascript.
Te inputy które mają być niewidoczne mają display:none.
Dane z formularza wędrują do bazy. Dla przykładu:
- jeśli user wybierze w select 'dvd' to wyświetli mu się input do wpisania rozmiaru w MB. Do bazy wędruje więc wpis do tabeli PRODUCTS_PROPERTIES zawierający id DVD oraz id PROPERTY (czyli MB).
- jeśli wybierze 'mebel' to wyświetli mu 3 inputy - 'szerokość', 'długość' i 'wysokość'. Tutaj do bazy wędrują 3 wpisy do PRODUCTS_PROPERTIES - id zawierający MEBEL i id PROPERTY. Raz dla szerokości, raz dla długości i raz dla wysokości.

User trochę cwańszy od przedszkolaka może mi wysłać formularz gdzie wrzuci w input DVD oraz SZEROKOŚĆ i WYSOKOŚĆ. Stworzy to bzdurne wpisy oczywiście.
Nawet jeśli zmienię skrypt JS, żeby nie generował inputów, które obecnie sa po prostu ukryte, to nadal da się przecież wysłać formularz zawierający inne pola niż ten co wyświetlam.

Jak się przed tym ochronić?

Musisz sprawdzać przed zapisem czy do danego produktu przynależą właściwości, które dostałeś z formularza.

Dobra, czyli kombinuję tak...

tabela PRODUCT:
id | name | type
1 | Rambo | dvd
2 | Stół | mebel

tabela PROPERTIES:
id | name | type
1 | size | dvd
2 | width | mebel
3 | height | mebel
4 | length | mebel


Jeśli user w select wybrał 'dvd' to porównuję PRODUCT.TYPE z PROPERTIES.TYPE i jeśli jest taki sam to zezwalam na wpis do tabeli łącznikowej PRODCT_PROPERTIES? Dobrze kombinuję?

Porównanie porównaniem, tutaj chodzi o to, co wpisze użytkownik, np. dla DVD w polu input type="text" wpisze 'ala ma kota', bo to go puści. Musisz już na poziomie formularza zabezpieczyć wartości wpisane do formularza, więc dla dvd np. input type="number" step="0.1", będziesz miał pewność, że będzie to wartość float dla rozmiaru płyty.
Tylko mi nie mów, że musi być type="text" bo takie założenia projektu, bo jeśli tak, to są po prostu złe.

I tak, i nie. DOM-em można manipulować do woli, dlatego _wszystko_ co przyjdzie od użytkownika _trzeba_ zwalidować na backendzie.

Walidacja to już inna sprawa, pisze o rzeczach podstawowych

gino no wlasnie wprowadzasz w blad


No wlasnie nie bedzie mial tej pewnosci bo user nadal moze tam wstawic co mu sie zywnie podoba. Jak napisano, walidacja ma byc po stronei backend i tyle. To co napisales to co najwyzej ulatwienie dla uzytkownika a nie zadna pewnosc dla autora.


Chyba tak. Pokaz kod gdy juz to sprawdzanie napiszesz

nospor pisałem to z naprawę wielkim wyważeniem i zapenmiam Cię, że chodziło mi tylko o strukturę formularza, i oczywiste jest co piszesz. Natomiast zaraz posypią się pytania jak zrobić sanityzację i walidację danych. I tutaj lezy sedno problemu bo użytkownik ma braki w podstawach absolutncyh.

Napisales wyraznie:
"będziesz miał pewność, że będzie to wartość float dla rozmiaru płyty."
a to jest nieprawda i wprowadzanie autora w blad. Ja nie wnikam czy piszesz o formularzu czy nie. Skoro mowisz ze to mu daje pewnosc, no to mijasz sie z prawda i tyle w temacie.

Wartości wpisane do formularza, nie wysłane, ale ok, nie chcę zaśmiecać wątku i dochodzić racji.

Uzytkownik moze zmodyfikowac to pole i wstawic co mu sie zywnie podoba i nie wyslac. Pasuje?