Autor Wątek: Przejście stron, pobieranie tabeli JSON HTML JS  (Przeczytany 1278 razy)

Offline Yabol

  • Użytkownik

# Styczeń 30, 2017, 22:31:57
Cześć! Zawodowym web-masterem to ja nie jestem ale trzeba się na czymś uczyć i zrobić coś dobrze. Mam w bazie danych umieszczone pewne rekordy chcę je pobrać i wyświetlić w tabeli ale owe rekordy mogą należeć do różnych użytkowników i dla każdego chcę mieć osobną tabelę w html więc mam dwa wyjścia, albo utworzyć kod html ( tabel ) i przesłać wszystkie tabele z kodem html albo
przesłać same rekordy i z pomocą JS'a tworzyć tabelę, krok po kroku:
- Pobieramy ilość użytkowników
- Wysyłamy do serwera zapytanie żeby wysłał nam rekordy dla danego użytkowika, tworzymy tabelę ( tą czynność powtarzamy dla każdego użytkownika )
Tak to powinno wyglądać ?

Strona wielojęzykowa, pytanie jak ? Uruchamiając stronę w adresie mam np. www.strona.com/index.php i w tym pliku tam gdzie mam tekst to wpisuje funkcję np. getInLang('eng', id_tekstu); ?

Jak działa logowanie się używając <form action="php/login.php" method="post"> uruchamia się plik login.php w tym pliku mam całą procedurę logowania i w tym pliku jest coś takiego jak header("Location: ../web.php"); odpowiadające za powrót do strony logowania bądź przejście do nowej ale przy powrocie nastepuje przeładowanie całej strony ? Mogę umieścić w niej nowe "dane" za pomocą php np. informacje o złym haśle ale czy nie lepiej zrobić tego na JS skoro bez JS'a strona nie będzie spełniała swojej funkcjonalności ?


Edycja: Na tabelkach będą przeprowadzane operacje za pomocą JS'a
« Ostatnia zmiana: Styczeń 30, 2017, 22:38:12 wysłana przez Yabol »

Offline Mr. Spam

  • Miłośnik przetworów mięsnych

Offline lethern

  • Użytkownik

# Styczeń 31, 2017, 01:02:34
Powiedziałbym, że nie ma dużej różnicy między tym, czy stworzysz tabele po stronie serwera i wyślesz je klientowi, czy też zrobisz je w JS po stronie klienta; i wydaje się, że duże serwisy (za dynamiczne odpowiedzi) również stosują raz jedno, raz drugie podejście (pod gmailem znajdziemy Ajaxy z Jsonem, pod twitterem widzę sporo HTMLa)
Zrób tak jak Ci wygodniej, czyli czy wolisz generować HTML w php, frameworku php, czy w JS (czystym, albo jquery, albo frameworku JS)

Po co pytać serwera o każdego użytkownika.. Nie lepiej zapytać go o komplet danych? Tak i w przypadku JSON, jak i HTML

Ogólnie mam wrażenie, że pytasz nas, czy renderowanie strony zrobić w PHP czy w JS - to podobne pytanie, jak to czy napisać stronę w PHP, czy ruby, czy C#, czy... A na takie pytanie nie ma już jednej słusznej odpowiedzi
Dalej, żeby odpowiedzieć na to, jak napisać stronę wielojęzykową, proponuje ustalić w jakiej technologii i frameworku to będziesz robił, spróbować z google, powinien znaleźć Ci odpowiedź i przykłady
« Ostatnia zmiana: Styczeń 31, 2017, 01:04:18 wysłana przez lethern »

Offline Yabol

  • Użytkownik

# Styczeń 31, 2017, 10:09:25
$sql = "SELECT * FROM tbl_data WHERE user_id = 1";
$result = mysqli_query($connection, $sql);

$emparray = array();
while($row =mysqli_fetch_assoc($result))
{
        $emparray[] = $row;
}

echo json_encode($emparray);

Chcę pobrać nazwę użytkownika którego dane są pobierane oraz  rekordy dla tego użytkownika. Tutaj pobieram dla użytkownika o id 1 ale muszę do tego wcześniej pobrać osobnym zapytaniem nazwę użytkownika. Możliwe jest zapytanie: $sql = "SELECT usr_name FROM tbl_usr WHERE id = 1 AND SELECT * FROM tbl_data WHERE user_id = 1";

Offline Xenox93

  • Użytkownik

  • +1
# Styczeń 31, 2017, 11:15:03
Zapytania, którego potrzebujesz nazywa się - podzapytanie skorelowane, za pomocą, którego:
1) Wyświetlisz dla każdego użytkownika interesujące Ciebie dane (nawet z kilku tabel - JOIN itp.)
2) Otrzymasz nazwę użytkownika, ich ilość itp.
3) Możesz sobie pogrupować/posortować odpowiedzi wg użytkowników itd.

Nie wiem czy to zapytanie podane przez Ciebie na końcu jest prawidłowe, ale chyba tego tak się nie robi. Pierwszy lepszy link i chyba najodpowiedniejszy dla Ciebie http://www.sqlpedia.pl/podzapytania-skorelowane-sql/ Odpowiednikiem klienta z podanego linku będzie twój użytkownik.

Ogólnie rzecz biorąc lepiej jakbyś udostępnił API(?) czy coś, za pomocą, którego udostępnisz tylko dane, które chcesz przekazać. Ma to na celu uniknięcie różnego rodzaju wycieków danych lub wstrzykiwania kodu SQL itp. Skoro bazę danych udostępniasz na zewnątrz to trzeba zadbać o jego bezpieczeństwo jeszcze bardziej niż w przypadku zwracania wyników przez serwer. Co do tworzenia kodu HTML itp. to może to już wykonywać klient.

Dlaczego wspomniałem o SQL injection? Otóż zapytania typu SELECT * FROM Tabela najłatwiej zhackować :/

Offline Yabol

  • Użytkownik

# Styczeń 31, 2017, 11:45:54
Ogólnie rzecz biorąc lepiej jakbyś udostępnił API(?) czy coś, za pomocą, którego udostępnisz tylko dane, które chcesz przekazać. Ma to na celu uniknięcie różnego rodzaju wycieków danych lub wstrzykiwania kodu SQL itp. Skoro bazę danych udostępniasz na zewnątrz to trzeba zadbać o jego bezpieczeństwo jeszcze bardziej niż w przypadku zwracania wyników przez serwer. Co do tworzenia kodu HTML itp. to może to już wykonywać klient.
Mógłbyś rozwinąć ?

Offline Xenox93

  • Użytkownik

# Styczeń 31, 2017, 12:53:02
Tu masz opis czym jest API
http://forum.pasja-informatyki.pl/1256/co-to-jest-api

//===============================================================
// INFORMACJE O API
//===============================================================
Rozwiązań tego problemu jest całkiem sporo, np.:
* Zastosowanie protokołu HTTPS
* Zastosowanie wcześniej wspomnianego JSON'a
* połączenie powyższych
* WebSockets - http://www.merixstudio.pl/blog/websockets-jak-dziala-i-gdzie-stosowac/
* wiele innych sposobów na wymianę danych - pamiętaj na wymianę danych

Ogólnie rzecz biorąc, chodzi o to, aby nie dopuścić do sytuacji, gdzie każdy może mieć dostęp do bazy danych.

Wyobraź sobie Twitter lub Facebook, który udostępnia swoją BD całemu światu xD Oni udostępniają swoje API, czyli programowanie obiektowe (choć nie koniecznie - wtedy tworzysz bibliotekę), za pomocą, którego udostępniasz struktury/klasy/funkcje tylko te, które chcesz udostępnić.
Wewnątrz każdego API/biblioteki parsujesz HTTP(S) i/lub JSON'a, ale nie pozwalasz zwykłemu użytkownikowi na podejrzenie JSON'a, tylko może zobaczyć to co Ty chcesz aby było publiczne.

Użyteczny w tym przypadku jest wzorzec architektoniczny MVC(Model-View-Controller) lub MVVM, czyli dzielisz kod na warstwy. Nie jest to konieczne, ale z czasem warto się z nim zapoznać. Idea jest taka, że Controller lub ViewModel udostępnia gotową strukturę z danymi, która ma służyć do wypełnienia czegoś, np. tabeli. Dla przykładu jeżeli twoja tabela ma kolumny:
[ID] [nazwa_użytkownika] [Imię] [Nazwisko] [inne rekordy]

To twój Controller/ViewModel udostępnia tylko te dane, nic innego. Nie ma mowy o pokazaniu czystego JSON'a otrzymanego od serwera.

//===============================================================
// INFORMACJE O SQL Injection
//===============================================================
W dolnym linku spójrz na rozdział Technical implementations
https://en.wikipedia.org/wiki/SQL_injection

lub

http://www.w3schools.com/sql/sql_injection.asp

Dzięki temu otrzymujesz wszystkie dane jakie zawiera dana tabela. O zgrozo jeśli trzymasz w tej tabeli dosłownie wszystkie dane nawet hasła niezaszyfrowane/hash'owane :/

//===============================================================
// PODSUMOWANIE
//===============================================================
Reasumując, Nie musisz stosować programowania obiektowego(OOP) oraz wzorca architektonicznego aby zbudować coś na wzór API/biblioteki. Jednakże zastosowanie chociaż OOP ułatwi Ci implementację oraz rozwijanie funkcjonalności. Stosują to tak wielkie korporacje jak Twitter API czy Facebook API/Platform. Nie warto spoczywać na laurach nawet jeśli nie udostępnisz BD światu, gdyż warto ustrzec się w ogóle przed tak sformułowanymi zapytaniami do bazy danych. Oczywiście pomijam fakt, że im więcej będziesz miał logiki/funkcjonalności na stronie tym bardziej powinieneś zastanowić się nad .NET ASP lub Java EE( Spring Framework ).

Offline lethern

  • Użytkownik

# Styczeń 31, 2017, 16:37:04
Dlaczego wspomniałem o SQL injection? Otóż zapytania typu SELECT * FROM Tabela najłatwiej zhackować :/
Uściślając, to jednak tego zapytania nie da się "schakować", bo nie ma w nim żadnego parametru, typu
"select * from tabela where "+$user_inputchyba że miałeś coś innego na myśli

Pobrać dane z SQL możesz np. tak (załóżmy, żeby było trudneij, że masz dostępny identyfikator)
SELECT U.usr_name, D.*
FROM tbl_usr U
JOIN tbl_data D ON U.id = D.user_id
WHERE D.user_login= ...
W miejsce wielokropka powinna być jakaś zmienna, akurat nie wiem jak to PHPowcy robią

SQL Injection to takie zagrożenie, gdy wysyłasz do bazy zapytanie złożone ze sklejonych stringów, gdzie jeden z nich to input usera bez wcześniejszej obróbki, natomiast poprawne podejście to ręczne "escape" tego inputu który pochodzi od użytkownika, i/lub przy pomocy mechanizmu do wstawiania parametrów
(jakiś link http://php.net/manual/pl/function.mysql-real-escape-string.php)
« Ostatnia zmiana: Styczeń 31, 2017, 16:44:19 wysłana przez lethern »

Offline Xenox93

  • Użytkownik

# Styczeń 31, 2017, 18:09:41
Uściślając, to jednak tego zapytania nie da się "schakować", bo nie ma w nim żadnego parametru, typu
"select * from tabela where "+$user_inputchyba że miałeś coś innego na myśli
Tak, ale wcześniej Yabol wspomniał, że używa takiego zapytania
$sql = "SELECT * FROM tbl_data WHERE user_id = 1";

[...]

[code]$sql = "SELECT usr_name FROM tbl_usr WHERE id = 1 AND SELECT * FROM tbl_data WHERE user_id = 1";
[/code]
Gdzie łatwo można wywnioskować, że za jakiś czas user_id nie będzie miał przypisaną wartość 1. A będzie musiał użyć zmiennej.

Owszem SQL Injection jest spowodowane brakiem filtrowania wejścia, ale ciekawe czy Yabol zadbał o to. Dodatkowo podobny atak można wykonać bawiąc się w inżynierię wsteczną, gdzie w kodzie asm można celowo zmienić zapytania. Mowa o aplikacjach na desktopy. W Web zapewne istnieje możliwość przechwycenia HTTP (HTTPS jest już bezpieczne) wraz z danymi do bazy danych: dane logowania do BD, zapytania itp. Co więcej ilość możliwych technik ataku BD zawsze się zmienia, pojawiają się luki w ich serwerach. Więc im mniej się wysyła do sieci, jedynie to co rzeczywiście ma znaczenie to unika się większości ataków.

Gdyby udostępnienie BD światu byłoby bezpieczne, to różne portale społecznościowe i nie tylko udostępniałyby w kodzie taką możliwość. W lepszej sytuacji są użytkownicy PHP, których kod wykonuje się po stronie serwera, natomiast Yabol chce użyć JavaScript lub HTML, co niestety, ale wykonuje się po stronie klienta + w pakietach.

Oprócz SQL Injection można się wspomóc Conditional responses sprawdzając co zwróci zapytanie URL, ogólnie możliwych sposobów przeprowadzenia ataku jest całkiem sporo, kończąc na DDoS.

lethern nie zrozum mnie źle. Masz cały czas rację, gdyż udostępnianie BD na zewnątrz może mieć sens, ale wymaga większej wiedzy na temat bezpieczeństwa i zagrożeń. To co wyżej napisałem, może się nie wydarzyć jeśli zastosuje się pewne zabezpieczenia, ale mało kto czyta książki/blogi/publikacje nt. zabezpieczenia się przed kradzieżą danych z BD. Niestety, ale albo ktoś będzie najlepszy w programowaniu albo w bazach danych. Na pewno lepiej zapobiegać niż łatać.

Offline Yabol

  • Użytkownik

# Luty 01, 2017, 00:26:40
Profesjonalistą nie jestem w bazach danych ale chyba nic się nie stanie jak poćwiczę. A więc, o tym zabezpieczeniu przy przesyłaniu stringów to wiem ale zastanawia mnie co mam rozumieć poprzez udostępnienie JSON'a ?
    // Wypełnienie tablicy danych do wysłania
    var postData = {
        'data_str'      :  zmienna,
        'data2_str'   : zmienna2,
    };

    // Wysyłanie
    $.post( "php/add_contact.php", postData , function( data ) {
    // data to to co przyszło od serwera
});
Takie rzeczy mam w JavaScript, i czy to jest źle ?
Nie mam zamiaru nikomu haseł udostępniać na to jest osobna tabela, po zalogowaniu w sesji będę przechowywał tylko ID zalogowanego użytkownika a nie hasła

Offline Karol

  • Użytkownik

# Luty 01, 2017, 09:01:09
W miejsce wielokropka powinna być jakaś zmienna, akurat nie wiem jak to PHPowcy robią
Używają bindowania parametrów z PDO :) W query masz same tokeny, a w tablicy przekazujesz wartości dla tych tokenów.