Walidacja PHP (Wpisanie do bazy danych zapytania SQL)

Question

Witam, mam następujący problem. Napisałem skrypt kodujący w php na zaliczenie. Wymagana jest jednak walidacja (nie chodzi tutaj o długość itp) ale o wrzucenie jakiegokolwiek ciągu tekstu, znaków i nawet samych zapytań sql do bazy bez rozwalania samej bazy. Czy da się ten cały ciąg znaków które zostaną wpisane wrzucić do jakiegoś rodzaju nawiasu i to co będzie w środku to dla bazy oraz php będzie tylko ciąg który wrzuci się do bazy? Dziękuje za pomoc ;)

Answer 1

Walidację lepiej robić na poziomie tak zwanego języka bazy danych, czyli trigery itp, niż na poziomie back-end, bo jest za duże ryzyko, że ktoś zmieni back-end i skasuje walidację. Przypominam że aplikacje są zwykle trójwarstwowe, część front-end, back-end, i serwer bazy danych SQL. Części te są niezależne i komunikują się ze sobą. Triger na poziomie bazy danych zwraca komunikat, że dane są niepoprawne. Powinien podać kod błędu i z tego kodu wiesz jaki komunikat dać użytkownikowi. Ze względu na współdzielenie, konieczne jest dokonywanie zmian z użyciem transakcji. W pętli wykonujesz kilkakrotnie próby zmiany rekordu, po losowym odstępie czasowym aż nie ma komunikatu o niepowodzeniu. Jeśli kolejna próba kończy się niepowodzeniem, wycofujesz transakcję w bloku obsługi wyjątku. Ostatnia instrukcja przed blokiem obsługi wyjątku zatwierdza transakcję.

Comments

To jest całkowicie złe podejście. 

1. Po co realizować zapytanie do bazy, skoro na poziomie aplikacji możesz odrzucić nieprawidłowe dane. 
2. Podział na warstwy występuje w backendzie. 
3. Przenoszenie logiki do bazy danych to naprawdę niezbyt mądry pomysł. Po to realizuje się połączenie za pomocą PDO, używa abstrakcji żeby baza danych Cię nie interesowała. 
4. Serwis oparty na architekturze o której pisałeś pada po skoku aktywności z zapisem/updatem. 
5. Zapytania do bazy w pętli, to coś czego należy unikać. 
6. Frameworki ścigają się o ms w responsach http, a Ty proponujesz robić sleepa? 

---

Nie mam pojęcia jak ktoś może zmienić backend.

Tak jak kolega wyżej, zapytania mysql powinny być już zwalidowane, według dobrej praktyki, która ogranicza ilość zapytań myql.

---

bo jest za duże ryzyko, że ktoś zmieni back-end i skasuje walidację.

O tym już nawet nie pisałem, bo to... Ech. Jak się wchodzi na serwer to nie po to żeby skasować walidację, tylko po dump bazy danych. Potem wysyłasz tylko adres portfela BTC.

---

@Ehlert, W niektórych książkach są dyskusje czy robić walidację na poziomie back-end czy na poziomie bazy danych. Według mnie maksimum walidacji powinno być na poziomie bazy danych a jak już w żaden sposób nie możemy jej tam zrobić, to robimy ją w back-end, żeby baza danych była niezależna od back-end, przynajmniej w takim zakresie w jakim nieprawidłowe dane spowodują brak spójności danych. Język bazy danych często przypomina Pascal i jest łatwy do nauczenia. Niektóre trigery muszą być zastosowane bo nie da się wszystkiego zrobić na poziomie back-end. Oczywiście że programista celowo nie kasuje walidacji.  Mogą zdarzyć się przypadki, szczególnie przy konserwacji programu, że się przeoczy walidację w back-end i baza danych się wysypie. Co do transakcji to zawsze tak się robi, że jak jest wielodostęp to może transakcja zajechać jedna na drugą. W zależności od tego co w rekordzie było zmienianie odpowiednia procedura ma zastosowanie. Jeśli pewne pola mogą być zmienione niezależnie, nie musimy zatrzymywać programu dla interwencji użytkownika. Po prostu wycofujemy transakcję i w kolejnym przejściu pętli próbujemy znowu ją zatwierdzić. W praktyce wystarczą trzy próby powtórzeń co kilka milisekund. Zachodzenie na siebie transakcji będzie bardzo rzadkie bo ono jest na poziomie blokowania rekordu. Do zapytań SELECT  tego się nie stosuje tylko do zapisu głównie UPDATE. Nie rozumiem tez skąd takie dziwne rozgoryczenie. Takie rzeczy się stosuje rutynowo od wielu lat.

---

Ile widziałeś aplikacji na produkcji działających w taki sposób?