Мир php моими глазами

Хотел вначале по посту о каждой - но понял что лучше все написать вместе. Вот самые распространенные тупые решения при создании авторизации пользователей на сайте:

1. Email в качестве логина -  пожалуй, первое место в списке тупых идей. Сама идея такого подхода как раз-таки направлена на то, чтобы пользователю было проще регистрироваться. Типа вбивать меньше данных и все такое. Но на деле получается как раз наоборот - пользователь регистрируется не только на этом сайте, причем в большинстве случаев он вводит логин и пароль и ни разу не мыло в качестве логина. Он привыкает к этой паре логин-пароль и для него вбивать емэйл просто неочевидно, непривычно, не говоря уже о том, что если мыльников штук 5 - то какой именно был вбит при регистрации - вопрос достойный Что? Где? Когда?. Ну а если в форме авторизации еще и не подписано что вводить надо емэйл - ууууууууу
2. Ограничения на выбор пароля - секъюрность - это круто, несомненно. Только вот пользователь привыкает к своей привычной паре логин-пароль. А вот если привычный пароль не проходит ограничения, выбирает новый, который с 90%-й вероятностью забудет тут же как вбил. На следующем заходе запросит восстановление - и пароль будет пылиться на мыле и каждый раз он будет заходить на мыло, смотреть пароль и вставлять в форму Вы считаете, что ваш аккаунт на вашем сайте - самое важно в жизни пользователя? ну-ну :)) Безопасность - это важно, когда нужно. Пусть пользователи сами решают, важен для них ваш сайт или он достоин пароля 12345.
3. Капча + подтверждение email-а в регистрации - одной капчи с головой хватит чтобы вырубить ботов. Да есть метод леммингов для ее обхода, но много ли кому не влом его прикручивать? С подтверждением по emailу (активацией аккаунта) есть вечная проблема - обязательно у какого-нить письма не будут приходить. Или они в спам уйдут или еще какая-то фигня случится - неважно, так есть и будет. Не лучше ли высылать письмо со ссылкой на отписку, если ввели не правильный мыльник, чем на активацию? Да и настолько ли важно знать мыло пользователя для вашего сайта?
4. Нераспознаваемая капча - кто-то криворукий создал новый тип капчи и все начали его пользовать. Не знаю видел ли кто - но я, человек из плоти и крови, вбиваю ее верно раза с 10-го.
5. Капча без возможности перезагрузки - какой бы капча не была простой - обязательно однажды она сгенерит что-то ну просто совсем нечитаемое. А если пользователь уже вбил всю анкету - перегружать страницу не есть круто, ибо чревато потерей данных в некоторых браузерах.
6. Лишние обязательные поля - какое вам дело как меня зовут или где я живу? Хочу введу хочу нет и нефиг делать это обязательным, поэтому для вас зовут меня "вапва" и фамилия "водаплвопвпвпавап".
7. Малое ограничение на количество безпроблемных попыток ввода верного пароля - например, после 5 паролей начинает вылетать опять же капча или пишет типа подождите 20 минут. Лично у меня паролей штук 20, не меньше, и юзал я разные в зависимости от ситуации, вначале одни, потом другие и т.п. за лет 10 накопилось немало вариантов... А тут 5 - и потом мучайся... а в сочетании с п.4 - уххх  как весело авторизоваться становится...
8. Блок при N неверных попыток авторизации - тут скорее дело не в идее блокировать доступ к аккаунту на время если кажется, что подбирают пароль, а в кривой реализации этого некоторыми товарищами. Так как куки чистятся - надо учитывать ip, с которого пытались это сделать, иначе кто угодно набьет другому N попыток авторизоваться всяким шлаком и заблочит ему на время аккаунт.

Продолжая тему тупых решений хочется отметить еще одно. Например вот такой кусок кода ну или аналогичный часто встречается в проектах, написанных не очень опытными программистами, точнее даже не очень знающими:

$seconds_count = 86400;

Не, я тут не буду писать про переменные и т.п. я буду писать про числа. Возьмем число в примере - слету и не разберешь че это такое вообще... Вот если бы:

$seconds_count = 24*60*60;

Эх, если бы те, кто вычисляет такие числа и пишут как в первом случае знали бы как устроены трансляторы кода, то никогда бы не стали ничего считать. На самом деле, все такие константы вычисляются на стадии формирования промежуточного кода. Одновременно с этим отсекаются недостижимые куски кода и т.п.

Другими словами, если код транслируется один раз, а потом берется уже откешированый, то смысла в этом нет вообще - ну один раз сделает комп вычисление умножения, которое само по себе очень легкое - что с того? Ну а если же нет - и php-код будет каждый раз интерпретироваться без сохранения промежуточных вариантов - то не проще ли врубить eAccelerator? Да и нужна ли такая типа оптимизация в проекте в котором все положили на реальное ускорение через кеширование?

Недавно наткнулся на интересную идею - на все типы ошибок повесить обработчик, который, если оная возникает, шлет письмо админу с указанием полного кода ошибки. На первый взгляд это действительно интересно, потому что гораздо проще проверять почту, чем колупаться в логах или ждать сообщений от пользователей. На деле же такое прокатит только на очень маленьких проектах, где посетителей очень мало.

Представим себе проект, который посещает человек 300 в день и у которого внезапно отвалилась база данных. Ну например, место кончилось или еще че-нить. Пользователь, который видит, что страница не загрузилась есстественно попробует ее перезагрузить несколько раз для верности. Ну и каждый раз есстественно письмо админу

Таким образом, пока админ успеет среагировать - его ящик будет переполнен ну или же, что скорее всего, сайт улетит в бан за спам и потребуется много времени чтобы объяснить почтовикам что он не спамер, а просто так получилось. Я имею ввиду, что спам-фильтр будет резать письма с этого сайта, которые идут на мыло админа.

Чтобы дать этой идее хоть какую-нить жизнь, нужно написать специальный анализатор, который будет разбирать ошибки и недопускать повторного отправления одного и того же, что в принципе довольно геморно, потому что написан он будет на php, стало быть если отвалятся некоторые php-шные части (например, отправка писем :)), то он все равно не сможет выполнять свою задачу.
Так что отправка писем с ошибками администратору - тупая идея

Недавно постучался ко мне в аську знакомый сеошник с проблемой - дескать не могут они с верстальщиком в уже готовый проект, написанный фиг_знает_кем_кого_уже_нет_рядом, код то ли счетчика то ли еще чего, другими словами javascript вставить не получается. Какой там шаблонизатор, да и вообще на чем проект этот написан, они понятное дело не в курсе, потому что один верстальщик, а второй сеошник а спросить не у кого. Я попросил прислать пример кода в html-ке (текста шаблона) и, как я и ожидал, оказалось что это Smarty.

Если кто не знает, в смарти используются разделители для того, чтобы обозначить что данный кусок кода все-таки написан на смарти а не просто текст. И хоть в доке по нему явно написано, что разделители дескать можно настроить любые какие только душе угодно - на деле же все используют именно то что там по умолчанию ( фигурные скобки ), ибо все готовое написано именно так, а переписывать готовое ради разделителя не айс ни разу.  Вот и получается что код javascript-а, обрамленный в блок (например function foo() { ... }, да или просто любой блок) шаблонизатор воспринимает как директиву Smarty и пытается его исполнить. И чтобы такого не возникало, придумали специальный костыль - обрамлять куски html, в которых встречаются разделители тегами {literal}тут код{/literal}.

Приятель, для которого код - это что-то из серии магии, воспринял это нормально. Их с версталем не бесило то, что они убили полдня на выполнение простейшей задачи. Но если бы они знали, что оффициально смарти (да и вообще любой шаблонизатор) нужен для того, чтобы разделить логику работы приложения от логики отображения и в куче зомбирующих постов про него написано, что верстальщикам проще редактировать шаблоны, написанные в нем, чем в чистом php, то наверное реакция у них была бы совершенно другая.

Концепция "Friendly URLs " в последнее время полностью извратила метод GET протокола HTTP. Никаких тебе index.php?path='blog'&record_id=100500 - все разделено слешами, даже этот пост, сайт без mod_rewrite кажется просто неполноценным. Однако остались еще места, где GET незаменим. Одно из таких мест - форма поиска.

У многих программистов (как правило, начинающих) в голове почему-то строится странное соответствие: формы = POST. Понятное дело, форма авторизации - постом, ибо показывать кому-то логин-пароль в урле - брррр, контактная форма - тоже пост и т.п.

(далее…)

CSV - один из форматов файлов. Удобен он тем, что позволяет заказчикам, непросвященным в вопросах технологий редактировать данные в обычном экселе, а программистам легко забирать то что они там понаписали. Заказчик делает обычную таблицу, сохраняет ее в формате csv - и получается файлик, в котором записи разделены по определенным правилам.

1. Каждая строка - это отдельная запись;

2. Записи разных колонок разделяются определенным разделителем (в основном зяпятая или точка с запятой);

3. Если в записи есть разделитель, то запись берется в кавычки;

4. Если в записи есть кавычки, то они представляются в виде 2-х кавычек;

(далее…)

Из всех книг по программированию меня очень зацепила книжка Бэка "Экстремальное программирование". Сама концепция так называемого test driven development-а, да впрочем и как и само парное программирование, да и идея что заказчик сидит рядом и всегда доступен и отвечает на вопросы, т.е. он часть команды - все эти идеи на данной ступени развития кажутся мне чем-то из области фантазий, которые практически не реализуемы, по крайней мере в той части мира программирования, в которой все мы варимся. Но что действительно было интересно, так эта их идея о том, что все задачи должны быть реализованы самым простым способом из возможных, в случае чего - всегда можно отрефакторить. Однако, как назло, в программировании считается очень крутым писать расширяемые, настраиваемые вещи - и это частенько порождает проблемы.

(далее…)

Вырезка прям из кода текущего проекта:

if (preg_match($regex, $address)) {
return true;
}
else {
return false;
}

(далее…)