Недавно писали как раз по этому поводу вопрос в суппорт. Т.к. запрос официальный как бы, думаем можно выложить просто цитатки.
p.s.: вообще не знаем почему, но нам на все вопросы в суппорт всегда везло. каждый раз когда что-то спрашиваем или просим помочь - получаем адекватный достаточно быстрый ответ с нормальными пояснениями.
html вставки надо кодировать javascript-том тогда уж, или банально через base64_encode. От идиотов поможет, остальные по любому взломают.
Даже если шифровать - ссылка удаляется без всяких проблем. Не в варезных целях, а просто для подтверждения своих слов
.htaccess php_value auto_prepend_file dellink.php dellink.php ob_start("bebebe"); function bebebe($a) { return str_replace('ссылка','',$a); }
ТС надо посмотреть в сторону проектов которые в изрядной степени компилят пхп код. Вроде бы такие веяния начинались, не знаем чем закончились. Но сама по себе идея - в целом лучшая из тех, что нам известны.
Тайна появления говнокода раскрыта 😂
Зенд как решение для защиты кода себя в достаточной степени дискредитировал. Зенд может выполнять 2 функции: обфускацию, перевод в байт-код.
Для первого существует огромное количество куда более тонко настраиваемых обфускаторов, более дешевых. Поэтому смысла нет.
По второму - декодер для зенда ищется за 15 минут гугления, и без всяких навыков расшифровывает все верно за пару минут. С точки зрения енкодеров лучше искать экзотику, которая выступает в роли "неуловимого джо" - которой никто особо не занимается. ion cube, что-то там от phped и так далее.
Zend как таковой имеет смысл только если Вы продаете распространенный продукт и готовы мирится с тем, что все кому не лень - его расшифруют. Но при этом он пойдет практически на всех хостингах и имеет ряд удобных плюшек, плюс стандарт де-факто для закрытого кода.
Но если речь идет именно о крутой защите - лучше выбирать другие решения.
p.s.: ссылки на обфускаторы уже приводили, так что повторятся не будем.
Если решать задачу "в лоб", это 50к запросов в базу. Если это вирт.хостинг, да еще мускул на отдельном сервере (в том смысле что запросы еще по сети гоняются), он не то что может упасть - он должен падать:)
Miracle,
по первому пункту подробнее не знаю как объяснить. Там простые условия:)
Т.е. 3 апдейта вида
update table set field=0; update table set field=3 where id=5; update table set field=10 where id=20;
заменяются на
update table set field=if(id=5,3,if(id=20,10,0))
По второму пункту, чуть сложнее. Но суть
update wp_posts set comment_count=(select count(*) from wp_comments where wp_posts.ID=wp_comments.comment_post_ID)
в том, что Вы делаете выборку count(*) количества записей для каждого отдельного поста, и выставляете ее в поле. Объединение идет по условию wp_posts.ID=wp_comments.comment_post_ID
Для Вашего примера это должно быть нечто вроде
update pr_blog set comment_cnt=( select count(*) from pr_blog_comment where pr_blog_comment.blog_id=pr_blog.blog_id )
И последнее что хотелось бы отметить.
$query = "SELECT blog_id , COUNT(blog_id) cnt FROM pr_blog_comment GROUP BY `blog_id` ORDER BY cnt DESC LIMIT ".($p*2000).",2000"; //приходится по 2000 делать, итак сервер падал в 502-504
Если бьете выборку, бейте ее как-нибудь однозначно. Тут лучше делать order by blog_id например. Т.к. количество комментов у Вас может оказаться одинаковым в разных блогах, и сортировка выборки при одинаковом кол-ве комментов будет непредсказуемой. То есть пары blog_id, count(blog_id) могут выбраться как 12, 10 ; 15, 10; 20, 10 или как 15, 10; 20, 10; 12, 10 ; . И если это попадет на границу лимита, то часть блогов можете упустить при апдейте, а часть проапдейтить дважды.
1) Можно слить в один запрос по методу: update table set field=if(id=1,3,if(id=5,8,9)) , только надо следить за длиной запроса... ну и вообще не перестараться. Пояснение: если ИД будет равен одному, то в комменты запишется 3... иначе... если ид=5, запишется 8 иначе 9. На автомате такой запрос легко обсчитается.
2) Очень вероятно что не надо так сложно пересчитывать. Можно по идее сделать одним запросом вида "update wp_posts set comment_count=(select count(*) from wp_comments where wp_posts.ID=wp_comments.comment_post_ID)" . Зависит от Вашей структуры базы конечно, но в большинстве случаев это более чем реально.
Второй способ намного душевнее и быстрее получается обычно. Первый несколько универсальнее, хотя и выглядит крейзанутым.
Из сообщения PHWizard "сайт мой не работает, сразу вспомнил, пишу в саппорт " однозначно следует, что хостинг.уа подождал 7 дней, а потом отформатировал сервер.
Если это так, то это достаточно неадекватное поведение. Кто мешал отключить сервер на 1-ый день и отрубить на 7-ой? Клиент сразу бы заметил и оплатил. Не говоря уже о том, что ошибки случаются, что если бы хостинг.уа отрубил бы не тот сервер? Мгновенное форматирование привело бы к обидам совершенно невинного клиента.
Если вырубили сразу, а отформатировали через 7 дней, то все наоборот. Тогда хостинг.уа рулит не по детски, а PHWizard не заметивший в течении недели не работающих сайтов - очень странный человек.
А Вы нет? Никогда? Ни для каких ситуаций? 100%-но и без лицемерия и понтов?
Макдо не рекомендуют, потому что его и так все знают. В незнакомой местности фастфуд уровня мака или повыше - для "быстропокушать" идеальный вариант. Ибо минимальный шанс нарваться на что-нибудь экзотическое или плохого качества или получить хамящего официанта. В отличии от неизвестных забегаловок, с неизвестной едой и правилами.
Утверждение что картинки нужно хранить только в БД или только в файлах - религиозно фанатично, а следовательно заведомо неверно.
1) Хранить картинки в БД иногда действительно имеет смысл, т.к.
1а) ФС может быть перегружена, а сервер БД вполне возможно живет отдельно. Скорость может оказаться выше из-за этого.
1б) Некоторые хостеры действительно ограничивают место на диске, но не место в БД.
1в) Если нужно вытаскивать картинки с разных фронтиндов, иногда проще кинуть их в базу как в центральное хранилище, не морочась кластерами и распределенной файловой системой.
1г) Проще следить за нагрузкой, т.к. она выделенная и вообще.
2) Хранить картинки в БД в общем случае не лучшая идея, т.к.
2а) Если сервер БД отдельный, то гоняется нехилый траффик между ним и основным сайтом, как следствие задержки и тормоза. А если этот траффик еще и считается, то еще и оплата за трафф.
2б) Если картинки выводятся по несколько штук на страницу, то в общем для вывода каждой из них нужно будет запускать скрипт (жрущий память и проц), устанавливать коннект к БД (коих бесконечно не бывает), запускать лишний процесс в конце концов для отдачи контента (что тоже не кул). Что в общем создает нагрузку.
2в) Сервер сложнее поддается оптимизации и требует больше ресурсов.
Пункт 2б, если речь о виртуальном хостинге, убивает весь смысл. Т.к. при том кол-ве места которое имеет смысл экономить, Вас раньше выгонят с хостинга за нагрузку, чем у Вас кончилось бы файловое место.
Если действительно суровая проблема с местом, то существует Н-ное кол-во бесплатных хостингов для картинок. Вполне можно раз в сутки заливать все залитое к Вам на хостинг - на бесплатные хостинги.
Опять же - в идеале - не решать за юзера. Пусть будет выбор. Подтверждение по паролю по смс на телефон, подтверждение на мыло, личный визит к ближайшему регистратору или нотариально заверенное заявление, колбак на контактный телефон, дополнительный суперсекретный пароль. Просто при установке запрета - выбираешь способ его снятия. В принципе выдумывать что-то особо новое не нужно, нам лично нравится система альфаклика, можно взять любую систему интернет-банкинга от нормальных банков за прообраз. Проблема-то далеко не новая.
Если уж на то пошло, то мы бы предложили легкий вариант
а) На каждый сервис trust/debt/credit и т.д. - своя галочка. И четко написанное правило, что договоренности вне системы вебманей не учитываются (оно и так есть, но не всем понятно).
или тяжелый вариант
б) Каждая операция подтверждается паролем приходящим на смс. При чем телефон меняется тоже только по смс паролю на него. Как на альфаклике в общем.
Собственно до пункта Б вебмани наверняка дойдет, есть ведь уже сообщалка об операциях на смс/емыл. Да платная, но стоит в общем очень недорого. И в общем может изрядно спасти.
Та же проблема была при получении мастеркарда нормального. Не выдавали категорически. Потом вспомнилось что ИП оформлено же, о чем и было менеджерам заявлено. Никаких документов и подтверждений об этом не спрашивали, а в качестве рабочего был оставлен сотовый телефон и всё на этом - выдали. Единственно что предупредили что бы для предпринимательской деятельности счет не использовался:)
Правило в принципе в чем-то логичное и понятно откуда ноги растут. Виза/классик и прочие аналогичного уровня карты позволяют платить в ряде случаев без онлайн-связи с банком. Той же прокаткой карты например. Можно залезть в минус. Так что это лишняя страховка для банка.
Не надо ориентироваться на размеры, размер имеет значение, но не здесь. Избавившись от вершины айсберга, вы лишь сделаете навигацию опаснее, потому что подводной части вообще не будет видно. Это - опасно.
Вы прочитали ссылку что мы дали? А то такое впечатление что Вы искренне считаете, что кроме кредитного мошеничества - ничего больше в вебманях провернуть нельзя. Перестаньте циклится на кредитах. Наоборот, взятие кредитов надо сделать еще легче и очевиднее и проще (развесить на айсберги флажки).
Потому что тогда человек получивший аттестат задумается о безопасности и применит один из нескольких легких и доступных способов обезопасится. А не тыкнет на галочку "не хочу кредитов" и забьет на безопасность вообще, потому что "ну тут же такое большое дело сделано, кредитов на меня не возьмут, ну и фиг с ним что повесят проблемы в 100 раз круче".
