"PHP" / Говнокод #27337 Ссылка на оригинал

0

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23
  24. 24
  25. 25
  26. 26
  27. 27
  28. 28
  29. 29
  30. 30
  31. 31
  32. 32
  33. 33
  34. 34
  35. 35
  36. 36
  37. 37
  38. 38
  39. 39
  40. 40
  41. 41
  42. 42
  43. 43
  44. 44
  45. 45
  46. 46
  47. 47
  48. 48
  49. 49
  50. 50
  51. 51
  52. 52
  53. 53
  54. 54
  55. 55
  56. 56
  57. 57
  58. 58
  59. 59
  60. 60
  61. 61
  62. 62
public function addMoney($name, $amount, $type)
	{
		$checkExist = $this->checkUserMoney($name);
		$checkExist = ($checkExist != '<b>(Ico)</b> <h11 style=\"color: red\">Произошла ошибка!</h11> <br/>') ? true : false;
		$name_uuid = $this->genUUID($name);
		
		if ($this->version == '1.12.2' AND $this->plugin != 'iconomy')
		{
			if ($checkExist)
			{
				if ($type == 'add')
				{
					$queryText = ($this->plugin == 'economylite') ? "UPDATE `economyliteplayers` SET `balance` = `balance` + '$amount' WHERE `uuid` = '$name_uuid' AND `currency` = 'economylite:coin'"
																  : "UPDATE `{$this->table}` SET `money` = `money` + '$amount' WHERE `player_name` = '$name'";
				} else
				{
					$queryText = ($this->plugin == 'economylite') ? "UPDATE `economyliteplayers` SET `balance` = '$amount' WHERE `uuid` = '$name_uuid' AND `currency` = 'economylite:coin'"
														          : "UPDATE `{$this->table}` SET `money` = '$amount' WHERE `player_name` = '$name'";
				}
			} else
			{
					$queryText = ($this->plugin == 'economylite') ? "INSERT INTO `economyliteplayers` (`uuid`, `balance`, `currency`) VALUES ('$name_uuid', '$amount', 'economylite:coin')"									  
																  : "INSERT INTO `{$this->table}` (`player_uuid`, `player_name`, `money`, `sync_complete`, `last_seen`) VALUES ('$name_uuid', '$name', '$amount', 'true', '0')";
			}
		} else 
		{
			if ($checkExist)
			{
				$queryText = ($type == 'add') ? "UPDATE `{$this->table}` SET `balance` = `balance` + $amount WHERE `username` = '$name'"
											  : "UPDATE `{$this->table}` SET `balance` = $amount WHERE `username` = '$name'";
			} else
			{
				$queryText = "INSERT INTO `{$this->table}` (`username`, `balance`) VALUES ('$name', $amount)";
			}
		}
		echo $queryText;
		$data = siteQuery($queryText, 'query', $this->mysqli);
		$text = ($data != NULL) ? "<b>(Ico)</b> <h11 style=\"color: green\">Игроку $name успешно начисленно: $amount эмеральдов!</h11> <br/>" 
								: '<b>(Ico)</b> <h11 style="color: red">Произошла ошибка!</h11> <br/>';
		
		return $text;
		
	}
public function checkUserMoney($name)
	{
		$name_uuid = $this->genUUID($name);
		
		if ($this->version == '1.12.2' AND $this->plugin != 'iconomy')
		{
			$queryText = ($this->plugin == 'economylite') ? "SELECT `balance` FROM `economyliteplayers` WHERE `uuid` = '{$name_uuid}' AND `currency` = 'economylite:coin'"
														  : "SELECT `money` as 'balance' FROM `{$this->table}` WHERE `player_name` = '{$name}'";
		} else 
		{
			$queryText = "SELECT `balance` FROM `{$this->table}` WHERE `username` = '{$name}'";
		}
		
		$data = siteQuery($queryText, 'assoc', $this->mysqli);
		$text = ($data != NULL) ? "<b>(Ico)</b> <h11 style=\"color: green\">Балланс игрока $name: {$data['balance']} эмеральдов!</h11> <br/>" 
								: '<b>(Ico)</b> <h11 style=\"color: red\">Произошла ошибка!</h11> <br/>';
		
		return $text;
	}

Этот говнокод кодил наш сотрудник https://vk.com/valiev_off, здесь вы можете наблюдать мастерские SQL запросы под тернарным соусом

Запостил: Dev1lroot Dev1lroot, (Updated )

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

  • > '1.12.2'
    > Балланс игрока $name: {$data['balance']} эмеральдов!
    https://mcskill.net/?page=shop-info
    < Покупка эмеральдов
    < Покупка игровой валюты на серверах.

    https://mcskill.net/mcforum/index.php?/topic/99675-немогу-зайти-в-аккаунт/
    <
    Доброго времени суток, 
    
    Для отключения 2фа на сайте обратитесь к следующим представителям администрации:
    
    https://vk.com/xraser или https://vk.com/valiev_off

    > 2002 г.
    Такой маленький, а уже PHP (。•́︿•̀。).


    > Запостил: Dev1lroot
    https://mcskill.net/?page=admin
    < Dev1lroot
    < Главный Фиксик

    Вот фиксиков на Говнокоде я ещё ня видела!
    Ответить
    • > отключения 2фа

      Несекьюрно как-то... В теории, проёб 2FA и бекапных ключей должен быть эквивалентен проёбу аккаунта. На практике, конечно, много где дыру с его отключением оставляют.
      Ответить
      • Судя по тому, что предлагается писать в личку админам (они же создатели, они же разработчики), процедура отключения 2FA представляет собой UPDATE users SET `2fa_active`=0 WHERE nickname=`Lexa1423`; (или какие там кавычки в мускуле нядо...).
        Ответить
        • Ну это конечно вы пост откопали древний) Во времена Валиева так и было, сейчас автоматика. Но процедура описана почти правильно ;D однако в мускуле `апострофы` это кавычки ключей, а для текста тупа 'такие'
          Ответить
    • а как инкрементят в средах без поддержки атомарного инкремента?)

      транзакцию делают, наверное
      Ответить
      • https://sqlperformance.com/2020/09/locking/upsert-anti-pattern
        BEGIN TRANSACTION;
         
        INSERT dbo.t([key], val) 
          SELECT @key, @val
          WHERE NOT EXISTS
          (
            SELECT 1 FROM dbo.t WITH (UPDLOCK, SERIALIZABLE)
              WHERE [key] = @key
          );
         
        IF @@ROWCOUNT = 0
        BEGIN
          UPDATE dbo.t SET val = @val WHERE [key] = @key;
        END
         
        COMMIT TRANSACTION;

        Вместо простого, быстрого и атомарного ON CONFLICT DO UPDATE — вот эта вот жесть. Кошмар.
        Ответить
        • кажется, можно вынести логику из SQL, сделать проще

          BEGIN TRANSACTION (уровень изоляции должно быть repeatable reads наверное)

          Потом SELECT по нужным условиям

          Получаешь результат, и делаешь if в своем любимом языке программирования.

          В зависимости от результата делаешь INSERT или UPDATE

          потом COMMIT
          Ответить
          • В том-то и проблема, что при таком подходе база будет два раза проверять одни и те же условия: снячала из твоего SELECT, а потом в INSERT/UPDATE. А нормальный UPSERT здорового человека делает один index scan на запрос — об этом человек в статье и пишет.
            Ответить
            • понятно, но во-первых я не уверен, что этот синтаксис переносим между субд, а во-вторых совсем не факт, что пенальти будет настолько большим, чтоб вот ради перформанса усложнять код
              Ответить
                  • Ну да, это для MS-SQL-холопов. Правильные постгрепацаны и постгрепацанессы делают ON CONFLICT DO NOTHING/UPDATE ... . У MySQL есть INSERT IGNORE, INSERT REPLACE и INSERT ... ON DUPLICATE KEY UPDATE, потому что MySQL для пыхеров, а пыхеры должны страдать.
                    Ответить
        • Какой багор ))) Именно поэтому я за `mnesia':

          mnesia:transaction(
          fun() ->
            mnesia:write(Key, Val)
          end)
          Ответить
          • Прошу прощения, спросонья ёба дал:
            mnesia:transaction(
            fun() ->
              mnesia:write(#my_table{key = Key, val = Val})
            end)
            Ответить
              • там вроде квери пишут на эрланге а не на сраном sql, если я ничо не путаю
                Ответить
              • Она во всё умеет. Берешь и оборачиваешь любой* код в `mnesia:transaction`, и он становится ACID c уровнем изоляции serializable. Есть `qlc' для "декларативных" запросов.

                * Без side-effect'ов
                Ответить
                • Mnesia это что вообще? Бд? Стор какой-то? Маппинг? Не стрёмно транзакции произвольной продолжительности открывать если они сериализуемые?
                  Ответить
                  • > Mnesia это что вообще? Бд?
                    Да.

                    > Маппинг?
                    Нет, это не ORM, там свой движок.

                    > Не стрёмно транзакции произвольной продолжительности открывать если они сериализуемые?

                    В общем случае, нет, не стрёмно. Убивай их по таймауту, если хочешь, она стерпит.
                    Ответить
                    • > В общем случае, нет, не стрёмно.

                      Кстати, а там какие-то гарантии на fairness есть? Или кто первый -- того и тапки, а какие-то длинные транзакции могут и вообще никогда не пройти.
                      Ответить
                      • > Кстати, а там какие-то гарантии на fairness есть?

                        Какие-то гарантии есть, а именно при разрешимом конфликте лочек, транзакции встают в очередь, отсортированную по их IDшнику (который часы Лапорта + pid транзакции). При неразрешимом — одна из них грохается и рестартует (емнип, самая старая). Отсутствие deadlock'ов эта схема гарантирует, отсутствие livelock'ов — нет. На практике я последних не видел.
                        Ответить
                  • > произвольной продолжительности

                    Судя по "без side-effect'ов" продолжительность у большинства из них весьма короткая...
                    Ответить
                      • > Иммутабельная БД. На каждый INSERT возвращается копия.

                        Это скорее к постгре с её vacuum, лол. В mnesia все значения очень даже мутабельные. (На уровне таплов)
                        Ответить
                        • тоже подумал про mvcc , да) Кстати, это не только у постгри так
                          Ответить
                          • А как по-другому сделать repeatable read, кстати? Вычищать ненужные кортежи сразу после того, как все транзакции, начавшиеся до коммита изменяющей, закоммитятся?
                            Ответить
                            • > как по-другому сделать repeatable read

                              Лочками на прочитанные строки, к примеру.
                              Ответить
                              • T1: прочитала строку 1
                                T1: изменила строку 1
                                T2: читает строку 1

                                Теперь у нас две версии строки 1, правда?
                                Кажется, одними лочками тут не обойдешься
                                Ответить
                                • T2: ждёт, пока T1 завершится, т.к. T1 взяла write lock на 1.
                                  Ответить
                                  • Это если serializable же, а если repeatable read, то она может читать старую версию, нет?

                                    Если T2 ничего не будет менять, то она вообще не должна страдать вроде
                                    Ответить
                                    • > Это если serializable же, а если repeatable read, то она может читать старую версию, нет?

                                      Да. Ну так речь про mnesia была вроде, она serializable.
                                      Ответить
                                      • а, сорь
                                        я о своем, о женс реляционноскульном

                                        постгря вроде repeatable read по умолчанию, а ms-sql вообще read commited
                                        Ответить
                                        • Да, я потом понял. Я SQLшнёй редко занимаюсь, поэтому у меня в голове просто изоляции вложены: serializable — подтип repeatable read, repeatable read — подтип read committed и т.д., как на этой диаграмме: https://jepsen.io/consistency

                                          Поэтому в ответе "с помощью лочек" на вопрос "как организовать repeatable reads" я уловил возможность сделать serializable, и тем самым, получить свойства базового класса, если так можно сказать.
                                          Ответить
                                          • > изоляции вложены

                                            Да, я тоже думал о "не хуже чем repeatable read" когда предлагал эти лочки...

                                            Насколько помню, во многих базах реализовано всего 1-2 уровня, а остальные превращаются в более жёсткие.
                                            Ответить
                                            • Гарантия работает в одну сторону: ты можешь реализоввать serializable, и формально выполнить стандарт, ведь ты выполнишь все гарантии более низких уровней.

                                              Думаю, read uncomitted никто не реализует (кроме mysql с myisam)
                                              Ответить
                            • Зависит от нужного isolation level. Чем он строже, тем легче. В мнязии reads блокируют writes, а writes пишутся в локальный для транзакции загончик, который при коммите дампится в основную таблицу.
                              Ответить
                              • судя по ссылке выше, оракл примерно также делает?

                                Oracle maintains old versions in rollback segments (also known as 'undo log').
                                Ответить
                                • Хрен знает, также или нет. Я оракла не трогал, к счастью. В мнезии transaction storage хранит новые данные, а не старые, так что это больше на staged chages похоже.
                                  Ответить
  • >iconomy plugin
    А вот такое, кажется, реально есть. "Иконами так иконами..."
    Ответить
  • > наш сотрудник [ссылка удалена]

    Здесь такое не поощряется. Мало ли кто какое говно на рассвете карьеры писал, зачем ссылку на его профиль увековечивать то?
    Ответить
    • Как? Разве мы не битарды? Разве не должны бы never forget, never forgive, деанонить, троллить, интернет-буллить и доводить человека до самовыпила?
      Ответить
      • Нястоящие битарды — NYPA, и должны задеанонить, затроллить, забуллить и задоводить ТСа.
        Ответить
        • Угу. Если начальник публично ругает и высмеивает сотрудника, какой бы хуёвый код он не писал -- такую контору лучше сразу слать нахуй. Айти -- не Пятёрочка. Здесь такие "менеджеры" не нужны.

          Мы в ответе за тех, кого приручили.
          Ответить
    • Я, кстати, более чем уверен, что этот код на самом деле написал ТС, а просто свалил на какого-то левого чувака, которому всё равно никто не поверит, т.к. ТС хуесос и пидррас >:[
      Ответить
      • Ну по факту ТС и предполагаемый автор действительно работают в одной "конторе", так что выглядит достоверно. Другое дело, что на первом-втором курсе писать говно — совершенно нярмально. А с учётом того, что из себя представляет эта "контора", ставлю усы, лапы и хвост чужие, что няписано оно на чистом энтузиазме, что вообще снимает все претензии.
        Ответить
        • > на первом-втором курсе писать говно — совершенно нярмально
          Это правда. Но вот только лучше делать это не на пхп
          Ответить
          • Да, PHP — это, конячно, зашквар. Пацаны и пацанессы за руку потом здороваться ня будут (⌯˃̶᷄ ﹏ ˂̶᷄⌯)゚.

            С другой стороны, в мире публичных пиратских серверов для Майнкрафта по-другому никак: там абсолютно всё завязано на PHP.
            Ответить
            • Просто в юности мозг же как губка: всё впитывает, и потому нужно стараться в него мусор не кидать. Оно же всё отпечатывается там
              Ответить
              • На ЙАЖЕ сама игра няписана, а пиратские обвесы для неё (все вот эти вот "игровые валюты", "премиумы", "античеты" и прочее дерьмо) — это PHP. Пример: https://github.com/new-sashok724/Launcher.

                Ай, нят, там PHP только в виде плагинов для всяческих вротпрессов. Зато ЙАЖА-говна полно!
                Ответить
                    • > if ((!$user = user_info($_SESSION['user']))

                      Прекрасно, восхитительно!

                      Это эталонный коД на ПХП, тут и хтмл, и ксс, и какое-то жкюри, кажется, только хсс не хватает, но может оно там и есть (я не знаю пхп).
                      Ответить
                      • Тут самой мякотки нет: загрузки и проверки валидности клиента (ня пиратских серверах свои собственные клиенты со всем, чем полагается). Там вообще обычно угар и содомия.
                        Ответить
  • Кстати, если $СОТРУДНИК быстренько сменит ссылку на свою страничку, пока никто не успел взять и запостить его ID, то никто его уже не сдеванонит в будущем.
    Ответить
      • А вдруг это всё хитрый план, чтобы я написал и меня сдеванонили? Лучше уж пусть файк напишет тогда )))

        Я, кстати, решил отказаться от ВК, особо ничего не поменялось, только смехуёчков теперь стало меньше.
        Ответить
        • > отказаться от ВК, особо ничего не поменялось

          А теперь попробуй отказаться от ГК.
          Ответить
          • Ну хотя бы ты няпиши, у человека же ня всю жизнь теперь пятно будет!
            Ответить
            • У меня ВКшная учётка давным-давно протухла... Не регать же новую.
              Ответить

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

Семь раз отмерь — один отрежь, guest!

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


    8