Сергей Береснев

$a = "string|name1,value1|name2,value2|name3,value3|...";
preg_match_all("/([^|,]+)/",$a,$matches);
var_dump($matches);

если есть пхп 5.3 (а не пхп4), то грех уже не использовать mysqli, и забыть про инъекции с плейсхолдерами как страшный сон. Плюс экономия на времени парсинга запроса как приятный бонус)
в зенде допустим:
$db->query('UPDATE users SET login_time=? WHERE id=?', array($time, $id));
выше уже говорили про PDO. но к сожалению он включен не по дефолту, а MYSQLI использовать можно вполне. Имитация magic quotes напомнила мне, если честно:

//Далее не безопасный код, но только так можно исправить ситуацию со старой версией.

if ($_GET) {
    foreach ($_GET AS $key => $value) {
        $$key = $value; //Делаю все переменные GET простыми, как это было с reg_glob
    }
}

>в статьях про архитектуру высоконагруженных систем (например, таких как twitter)
пока у вас нет нагрузок как у Твиттера, не делайте так. только усложните себе жизнь, написанием своих собственных джойнов на php

Подозреваю что систему прав делали именно для того чтоб нельзя было так просто добраться до папок/файлов не Ваших прав.

Мой Вам ночной совет. Институт — это «качалка» для мозга и куча воспоминаний. Остальное потом нагоните :)

xor

Флеш

0) Пара set'ов, если возможно как-то классифицировать их по паре признаков.
1) реализуйте в чистом виде по битовой маске int'а

Продавайте поддержку к коду.

«Если что-то работает — то не трогай это»

Пропарсить ответ.

Одно из самых простых — вешаем уникальный ключ принудительно, и сносим его.
ALTER IGNORE TABLE `backup` ADD UNIQUE ( `title`);
ALTER TABLE `backup` DROP KEY `title`;

Может подготовить образ на флешке и потом просто его разворачивать с нее?

Для научной ценности нужно придерживаться примерно такой структуры:
1. Находим проблему.
2. Делаем обзор существующих решений.
3. Определяем их недостатки.
4. Предлагаем своё решение, исправляющее все (скорее, несколько) из этих недостатков.
5. Проводим эксперименты, подтверждающие, что наше решение 1) действительно решает проблему, и 2) делает это лучше существующих решений.

Обязательность пунктов 2-5 накладывает ограничения на выбор пункта 1, о котором Вы спрашиваете.
Собственно, у Вас два варианта: либо php+mysql+js является объектом исследования, либо — инструментом. В первом случае можно поизучать производительность, предложить какой-нибудь свой плагин, оптимизирующий эту связку для какой-то конкретной задачи (например, посмотрите что можно оптимизировать в каком-нибудь open-source проекте). Во втором случае, когда php+mysql+js лишь инструмент, — задача может быть какой угодно: хоть моделирование жидкостей, хоть криптография, хоть финансовое прогнозирование — руководитель Вам подскажет.

Имхо, обычные способы бана по телефону бесполезны. Просто очень хорошо знаком с работой досок «изнутри» и с методами работы этих самых «некоторых товарищей».

Вот что эти товарищи будут делать, когда увидят сообщение «объявление не размещено, т.к. ваш номер телефона забанен на нашем сайте!»? Да они тупо возьмут другой номер и запостят своё объявление. И так до следующего раза.

На одном из своих проектов я решил проблему по-другому. Задача такая: максимально достоверно опознать «нехорошего человека».

Что я для этого делаю?

Если пользователь указал для своего объявления номер телефона, который у меня в чёрном списке, я:

1. ставлю ему бессрочные Cookie с меткой что данный пользователь — тот ещё петрушка;
2. также запоминаю в базе максимальное количество идентифицирующих его данных (IP, юзер агент браузера и т.д.);
3. его объявление сохраняю в базе и помечаю его как «полускрытое». Это значит, что объявление видно исключительно ему, для него создаётся видимость, будто всё прошло успешно и объявление опубликовано. На самом же деле, всем остальным пользователям сайта оно не показывается (в том числе незалогиненным);
4. если «нехороший человек» догадался, что я его обманул и теперь он вбивает очередной свой шлак, то, используя пункты 1 и 2 я снова его определяю, заношу в чёрный список уже новый номер, повторяю по новой пукнты 1 и 2.

В результате все «редиски» смотрят на мой сайт довольные, думают что я нормально опубликовал их объявления, не пытаются всеми возможными и невозможными способами обойти защиту (поскольку они подумали, что они её обошли), а в действительности сайт остаётся чистым.

На 98% серверов PHP хранит сессии в строго определенных папках (вариантов 10 всего, максимум), и в 99% с именем sess_[a-z0-9]+.
Если писать в сессию не фильтрованные данные, то можно сохранить на диск сервера. например веб-шелл, и при наличии local-include уязвимости, можно будет его исполнить.
Т.е сама по себе запись произвольных данных в сессию угрозы не представляет, но может быть использована для эксплуатирования других уязвимостей.

Обычно инклудяд log-файлы (предварительно оставив там вредоносный код), но они очень часто не доступны для чтения с правами php.
А вот подобрать путь до файла-сессии очень просто, а значит это облегчает потенциальный взлом.

Zend_Number
пример:

$locale = new Zend_Locale('de_AT');
$number = Zend_Locale_Format::getNumber('13.524,678',
                                        array('locale' => $locale,
                                              'precision' => 3)
                                       );
 
print $number; // will return 13524.678