Говнокод #19690 — PHP — Говнокод.ру

PHP / Говнокод #19690

+2
1. 1
```
https://habrahabr.ru/post/280121/
```
RestAPI в 2016 году. Отсосите, любители фреймворков и оттестированных библиотек

Запостил: loki90, 24 Марта 2016

Tweet
Комментарии (67) RSS
- guest 24.03.2016 23:13 # +3
  Плохой код потому что используется PDO
  Нужно собирать запросы в ручную, иначе не получится SQL инъекции.
  
  Но вот за вот этот вот кусочек кода я готов простить ВСЁ:
  
  } else view::error("Incorrect data type for: " . implode(', ', $wrong_types), 204); } else view::error("Missing parameters: " . implode(', ', $missing_parameters), 204); } else view::error("Method in developing.", 503); } else view::error("The method '" . $action . "' does not exist.", 204); } else view::error("No params received.", 204); } else view::error("Method was not received.", 204); }
  .
  
  Хиляки пишут классы на своих Java и C#, потом хилякам тулы генерируют .wsdlки, а другим хилякам по этим .wsdlкам генерируются клиенты
  
  Фу!
  Пых + рест наше все
  Ответить
  - inkanus-gray 24.03.2016 23:58 # +2
    
    Хороший программист и через PDO протащит инъекцию.
    Ответить
    - 3.14159265 24.03.2016 23:59 # +4
      
      Поехавший программист и через GKOD протащит ворецию.
      Ответить
    - guest 25.03.2016 00:01 # 0
      
      как?
      Ответить
      
      inkanus-gray 25.03.2016 00:04 # 0
      
      Можно подготавливать не все параметры, некоторые из них приклеивать вручную.
      
      Ну и ещё, как оказалось, готовые фреймворки фильтруют не всё:
      https://habrahabr.ru/post/140145/
      Ответить
      
      guest 25.03.2016 00:12 # 0
      
      Так тут люди именно фигачат мимо PDO склеивая вручную запросы потому что хотят делать и параметризировать такое, што субд не понимает
      
      Но вообще пыхопроблемы конечно
      В нормальных ЯП и фреймворках вроде Python/Django такого практически нет
      Ответить
  - gost 25.03.2016 07:15 # 0
    
    Какой красивый и чистый код!
    Ответить
  - istem 25.03.2016 22:26 # +2
    
    Простите, пожалуйста, но моё личное мнение - это - ебал я это ваше PDO. Говно оно - то ещё. Хотя бы потому, что в "multiple insert" не умеет. Потому что ограничивает всю мощь SQL. Потому что, это SQL-без-рук-без-ног, но только в фантике. А фантик играет лишь роль взрослого, когда играется ребёнок. Ну чтобы мамка не заругала.
    Фу, короче, так жить.
    PS. Заранее спасибо.
    Ответить
    - bormand 25.03.2016 22:29 # 0
      
      > "multiple insert"
      Можно пример, как этот multiple insert выглядит?
      Ответить
      
      istem 25.03.2016 22:34 # +2
      
      INSERT INTO (...) VALUES (...), (...), (...), ...
      Ответить
      
      guest 25.03.2016 22:38 # +4
      
      хахахахахахаха
      
      реально не поддерживает
      
      одного этого достаточно чтобы никогда не писать на PHP
      Ответить
      
      istem 25.03.2016 22:52 # 0
      
      Пхп - это для одних задач. Для обработки данных существует sql. А sql, как известно, язык множеств, которое это ваше pdo - откровенно посылает на хер. Хреново это всё.
      Ответить
      
      guest 25.03.2016 23:16 # +1
      
      Существует два способа работы с базами данных из языков программирования.
      
      Один способ называется prepared statements. Другой называется "через жопу" (он же "склеиваем строки вручную").
      
      Существует так же два вида языков: в одних через prepared statements можно описать DML. К таким языкам относятся python с его pep 0249, java с jdbc, с# с ado.net, perl с его DBI/DBD.
      К другим языкам (т.н. "очень плохие языки" или "языки в которых нужно вручную склеивать строки") относится PHP.
      
      Вопросы?
      Ответить
      
      bormand 25.03.2016 23:21 # 0
      
      У меня один вопрос - при чём здесь языки? Нормальную либу и на PHP можно написать.
      Ответить
      
      guest 25.03.2016 23:27 # +1
      
      Очевидно при том, что в нормальных языках принято писать нормальные драйверы
      
      А у ПХП такого драйвера нет, и никого это не ебет.
      В итоге приходят istemы, говорят что PDO говно, и начинают клеить SQL строки руками
      
      А потом SQL инъекции
      Ответить
      
      istem 26.03.2016 00:20 # 0
      
      Сам дурак.
      Ответить
      
      3_14dar 26.03.2016 20:14 # 0
      
      Можно, но она есть не везде. Ставить либы на php ведь сложно.
      Ответить
      
      guest 26.03.2016 20:16 # +3
      
      да тебе всё сложно
      Ответить
      
      inkanus-gray 25.03.2016 23:33 # +1
      
      Для prepared statements вовсе не обязательно использовать PDO. Можно обойтись Mysqli или другими драйверами для соответствующей СУБД.
      Ответить
      
      guest 25.03.2016 23:36 # +3
      
      да, хотя все равно отстой в том что код получается database-specific
      
      с другой стороны, для 89% это не важно
      
      PS: фуу
      инкаус знает mysql и php
      вот это зашквар
      Ответить
      
      bormand 25.03.2016 23:37 # +1
      
      От php и mysql не зарекаются...
      Ответить
      
      guest 25.03.2016 23:39 # +2
      
      я зарекся
      
      Вот я не шучу сейчас: не существует ни одного повода для меня использовать эти технологии
      Ответить
      
      inkanus-gray 26.03.2016 00:41 # 0
      
      От database-specific никуда не деться. При переходе с одной СУБД на другую зачастую приходится менять формат таблиц, потому что СУБД может не поддерживать требуемый тип данных.
      Ответить
      
      guest 26.03.2016 00:45 # 0
      
      базу нужно менять конечно, а причем тут код?
      код можно (если _очень_ повезет) сделать database-агностик и вообще не трогать
      
      У меня есть небольшой проектик на Django/Python, там всё через ORM и если я решу с постгри перейти на другую БД, я могу вообще не трогать паййтоновый код
      
      Но это конечно мне крупно повезло что он такой маленький
      В серьезных проектах приходится писать database-specific код
      Но все равно его там процентов 10%, не больше
      Ответить
      
      defecate-plusplus 26.03.2016 08:27 # +1
      
      типы данных и близко не основная причина db-specific кода, там и драйвер нормально справляется их селектить и апдейтить
      
      DDL же не обязательно выносить в прикладной уровень, ничего страшного, если это будет init скрипт, запущенный под конкретную базу 1 раз в жизни решения
      
      а вот мат вьюхи, рекурсивный обход, процедуры/пакеты, gis-расширения, олап - т.е. все то, что уже не попадает под "нам насрать в чем хранить данные форума из 3 таблиц, у нас пыхопе", а попадает под "давайте сокращать время селекта наших сложных данных", и надо дергать в рантайме из прикладного уровня - вот это да, это db-specific
      Ответить
      
      bormand 25.03.2016 22:46 # +1
      
      prepare + цикл с execute уже не катят? Они могут и побыстрее оказаться, чем эта срань (если внутри одной транзакции идут)...
      
      З.Ы. Ой, сорри, у вас же транзакций нету. Не подумал.
      Ответить
      
      istem 25.03.2016 22:50 # 0
      
      Да есть там всё. Но как обычно - через жопу. Но вот multiple insert - нету.
      Ответить
      
      guest 25.03.2016 23:27 # 0
      
      >>Ой, сорри, у вас же транзакций нету.
      у кого это "у вас"?
      Ответить
      
      bormand 25.03.2016 23:28 # +1
      
      У тех, кто юзает функции mysql_*.
      Ответить
      
      guest 25.03.2016 23:29 # 0
      
      ггг, mysql_query("START TRANSACTION"); работает
      Но лучше конечно $pdo->beginTransaction()
      
      в самой мускуле есть транзакции в InnoDB, нет их в MyISAM только
      Ответить
      
      bormand 25.03.2016 23:30 # 0
      
      > нет их в MyISAM только
      Я знаю. Но ты думаешь, что те, кто юзает mysql_* и клеит запросы через строки, юзают InnoDB?
      
      Они же либо сознательно пишут под говнохостинги (= myisam only) либо просто долбоёбы...
      Ответить
      
      guest 25.03.2016 23:31 # 0
      
      Так он там по-умолчанию уже тыщу лет, разве нет?
      MyISAM вообще депрекейтед
      Ответить
      
      bormand 25.03.2016 23:36 # 0
      
      Ну пишут, что в 5.5. Т.е. всего лет 7.
      Ответить
      
      bormand 25.03.2016 23:40 # +2
      
      Ну вот, к примеру, вбиваем в гугл "бесплатный хостинг php". Первой строчкой идёт какой-то hostinger. Смотрим описание тарифных планов. Во фришном поддержки innodb нет. Что и требовалось доказать.
      Ответить
      
      guest 25.03.2016 23:44 # +2
      
      в моем детстве в бесплатном хостинге и MySQL-то могло не быть
      
      А еще были такие хостинги где БД 4.0, а клиент от нее 3.23. Потому что админ тупой пидирас базу обновил, а php не пересобрал.
      
      Или например PDO есть, а драйверов к нему ни одного нет
      Ответить
      
      guest 25.03.2016 23:44 # 0
      
      Скажи мне, Борманд
      
      Ты бы хотел участвовать в проекте, у которого нет даже денег на хостинг"?
      Ответить
      
      bormand 25.03.2016 23:52 # +1
      
      Нет конечно. Но есть же добрые люди, которые пишут всякие форумчики, чтобы их можно было ставить на подобные говнохостинги...
      Ответить
      
      guest 25.03.2016 23:53 # +2
      
      а зачем?
      
      почему не использовать вконтакте? или ucoz?
      Ответить
      
      istem 25.03.2016 23:58 # +4
      
      Лур, залогинься уже. В конце-то, блять, концов.
      Ответить
      
      3_14dar 26.03.2016 20:16 # +3
      
      Потому, что вконтакте требует логина привязанного к телефону, да и вообще это два сайта, переход с которых будет сложным, в отличие от переноса пыхоговна на другой хостинг.
      Ответить
      
      inkanus-gray 29.03.2016 17:26 # 0
      
      Ещё во Вконтактике сообщество могут заморозить за внезапную смену тематики, за накрутку участников и вообще за любую подозрительную с точки зрения администрации ВК деятельность.
      Ответить
      
      guest 25.03.2016 23:32 # 0
      
      https://dev.mysql.com/doc/refman/5.5/en/server-options.html#option_mysqld_default-storage-engine
      
      5.5.5
      Ответить
      
      bormand 25.03.2016 23:37 # +1
      
      Ну ок, 6 лет.
      Ответить
      
      istem 25.03.2016 23:41 # 0
      
      В пыхе несколько напрягает клеить запросы через строки, (или даже через implode). Оное решается через sql-процедуру или триггер. А иногда и myisam - вполне так себе. Всё зависит от задач.
      PS. И не вижу ничего плохго в mysql_*, тем более если у товарищей прямые руки.
      Ответить
      
      guest 25.03.2016 23:42 # 0
      
      sql-процедуру -- это хорошо, но это создает отдельный уровень абстракции так как APIем базы становятся не таблицы а процедуры
      
      Кроме того процедуры нужно где-то хранить, версионировать, накатывать на сервер, итд.
      Ответить
      
      3_dar 26.03.2016 00:08 # +2
      
      > Но ты думаешь, что те, кто юзает mysql_* и клеит запросы через строки, юзают InnoDB?
      
      Ты думаешь, что те, кто юзает mysql_* и клеит запросы через строки знают что такое транзакции?
      Ответить
      
      guest 26.03.2016 00:13 # +1
      
      а разве на сбеседовании про уровни изоляции транзакций не спрашивают?
      Ответить
      
      bormand 26.03.2016 00:20 # +3
      
      На поклейщика строк?
      Ответить
      
      guest 26.03.2016 00:24 # 0
      
      Да, конечно
      
      http://goo.gl/IUz2fN
      Ответить
      
      roman-kashitsyn 26.03.2016 16:41 # +3
      
      > На поклейщика строк?
      
      Ещё вчера клеил стринги, а сегодня уже сайты пишет.
      Ответить
      
      guest 26.03.2016 17:12 # +4
      
      клеить нужно не стринги а тех, кто их носит
      
      девушки отличаются от яп тем, чем у них чары состоят из стрингов
      Ответить
      
      3_14dar 26.03.2016 20:16 # +1
      
      Звучит как "поклейщик обоев"
      Ответить
      
      gost 29.03.2016 17:23 # 0
      
      > У тех, кто юзает функции mysql_*.
      Такие ещё остались? О_о
      Ответить
    - guest 25.03.2016 22:31 # 0
      
      Что? Чем это оно ограничивает?? Ты с ORM не путаешь??
      Ответить
      
      istem 25.03.2016 22:35 # +1
      
      ORM - это мамка заругает, и ещё тётка и соседка.
      Ответить
      
      guest 25.03.2016 22:38 # 0
      
      ну да ну да, нужно годами хуячить одинаковый код руками с SQL инъекциями чтобы потом говорить "у меня 10 лет опыта пхп"
      Ответить
      
      istem 25.03.2016 22:49 # 0
      
      Да я уже вырос из этого. И сейчас я вообще не про инъекции. Инъекции - это инфантильность, я считаю.
      Ответить
      
      guest 25.03.2016 23:17 # 0
      
      Я тоже вырос, и в 99% случаев использую ORM
      А когда мне его не хватает -- я делаю prepared statements
      
      К счастью, я не пишу на PHP
      Ответить
      
      istem 25.03.2016 23:42 # 0
      
      > К счастью, я не пишу на PHP
      Ну тогда вы и вправду выросли. И если так, то зачем же над детьми смеяться? Лучше научите их как надо делать и как не надо.
      Ответить
      
      guest 26.03.2016 00:36 # −1
      
      С случайно зашел в :
      
      http://phpclub.ru/talk/forums/php-%D0%B8-%D0%B1%D0%B0%D0%B7%D1%8B-%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85.19/
      
      и завис
      
      не могу остановиться, читаю в захлеб
      Ответить
- myaut 24.03.2016 23:57 # +1
  
  public function orm($sql, $array, $type)
  Ответить
  - guest 25.03.2016 00:02 # +1
    
    Чувак уделал компанию RedHat, или кто там делает Hibernate :)
    Ответить
    - defecate-plusplus 26.03.2016 00:22 # 0
      
      кстати, любимый вопрос изи-левела на собеседовании, всегда ли надо использовать хайбейрнейт, или, может, у него тоже есть проблемы
      Ответить
      
      kegdan 26.03.2016 00:26 # 0
      
      Только когда используешь базу данных
      Ответить
      
      guest 26.03.2016 00:28 # +1
      
      За ответы "да, всегда" и "конечно никогда" нужно сразу гнать на мороз
      
      Кстати, а видели таких кандитатов которые говорят "у меня 10 лет опыта программирования под Oracle". "А напишите запрос для выбора всех польхователей из группы Foo во много-ко-многим" "Ой знаете, я напрямую запросов не писал никогда, у нас DAO и ORM"
      Ответить
- gost 25.03.2016 07:23 # 0
  if(($var === 'true') || ($var === true)) return true; elseif(($var === 'false') || ($var === false)) return true; else return false;
  
  Лол.
  Ответить
  - guest 25.03.2016 21:01 # 0
    
    Лолита
    Ответить
Добавить комментарий
Ошибка компиляции комментария:

Гости могут высказаться только в понедельник, среду, четверг или воскресение
Где здесь C++, guest?!

А не использовать ли нам bbcode?

[b]жирный[/b] — жирный

[i]курсив[/i] — курсив

[u]подчеркнутый[/u] — подчеркнутый

[s]перечеркнутый[/s] — перечеркнутый

[blink]мигающий[/blink] — мигающий

[color=red]цвет[/color] — цвет (подробнее)

[size=20]размер[/size] — размер (подробнее)

[code=<language>]some code[/code] (подробнее)

Проверочный код: *

Говнокод: по колено в коде.

PHP / Говнокод #19690

Комментарии (67) RSS

Добавить комментарий