На самом деле форма «напомнить пароль» в этому случае не нужна.
Если человек ввел email, который зарегистрирован в системе, и неправильный пароль от него, надо к красненькому тексту «Вы ввели неверный пароль», добавлять ссылку не «Восстановить пароль», а «Отправить письмо для восстановления пароля на xxx@mail.ru».
А после 2-ой неудачной попытки — отправлять это письмо автоматически.
«возможно у вас и так 100% открытие писем»
Совсем не так. Будь у нас 100% открытие писем — мы бы не заморачивались с конверсией и оптимизацией. Фактически подтверждают свой email менее 85%, а добавление большой синей ссылки «Открыть почту» (для мэйлру, яндекса и гмейла), вопреки ожиданиям, не изменило этот процент.
На украинских почтах распространенная практика — при получении первого письма каждым получателем, они присылают обратно отчет о недоставке с антиспам ссылкой для доставки письма. Нужен скрипт разбора инбокса аккаунта указанного в From — который автоматически будет переходить по этим ссылкам
Под плохой работой менеджеров я имел в виду, например, затягивание подготовки материалов для разработчиков. Пример: в понедельник должна быть готова вёрстка некоего раздела сайта. Утверждённый дизайн присылают только вечером в пятницу, со словами «к утру понедельника должно быть готово, мы обещали клиенту».
Кстати, это еще на удивление редкая и хорошая ситуация. Обычно присылают в понедельник после обеда, с мотивацией «Клиент должен был увидеть это еще утром, сейчас сидит жутко злой и звонит каждые 5 минут». Тогда не то что на выходных — приходится буквально ночью работать.
К таким вещам — только иммунитет. Сами заварили кашу — пусть сами и выкручиваются.
> программисты не могут мне дать чёткую эстимацию по задачам!
С этим ничего не поделаешь, но это немного другое. Если программист оценил задачу, т.е. у него было достаточно времени на её выполнение по его же собственной оценке — тогда в некоторых случаях (много чего завязано уже на дату предполагаемого запуска) можно и сверхурочно попросить поработать.
Всегда когда мне говорят про «срочную задачу», я отвечаю: «Не бывает срочных задач. Бывает плохое планирование.»
Из-за плохо сделавших свою работу менеджеров (плохое планирование), вынуждены тратить свои выходные разработчики, как правило не виновные во внезапном появлении «срочных» задач.
Как только ко мне пришло это понимание, я выработал иммунитет к «срочным» и особенно «сверхсрочным» задачам, и спокойно отдыхаю в свои выходные.
по статистике у нас 4.9 убийств на 100 тысяч человек
Эти цифры не показательны, т.к. в 99% случаев речь идёт про ситуации вроде «после совместного распития алкогольных напитков нанесла своему сожителю 12 ножевых ранений».
Насчет репутации — понятно. Но репутация это одно, а статистика по рассылкам — немного другое. Согласитесь, даже без подписи писем, я как отправитель имею право посмотреть процент прочитанных или отправленных в спам писем
Скажите пожалуйста, почему ваш Postmaster не заводится без DKIM, в то время как недавно появившийся «Почтовый офис» от Яндекса прекрасно работает без этой подписи?
«В перспективе не думаете переложить отдачу статики и подобные проверки на nginx?»
У нас используется похожая схема, и в ней есть nginx.
В нашей схеме наличие сгенерированного файла проверяет сначала nginx и если нужная картинка уже есть — отдаёт её своими силами.
Если же файл не найден — происходит передача запроса Апачу, а далее всё по похожей схеме как в данной статье
Вы перемудрили с антиспамом. У меня и у коллеги ящики на mail.ru, мы уже 5 лет активно переписываемся, но при этом год назад его письма началаи падать мне в «спам», а недавно мои начали падать в «спам» у него. Вопрос: почему вы сделали такой странный алгоритм антиспам? Спасибо за внимание к этой проблеме!
Речь, конечно, о встроенных в PHP сессиях. Ведь для авторизации в любом случае надо хранить где то на сервере соответствие «авторизационная кука»-«userid». Однако, сегодня я бы сделал это без использования $SESSION. Сегодня я бы хранил авторизационные сессии в кэше (быстро) и дублировал в БД — на случай обнуления кэша.
А хранить в сессии какие-то другие данные? Сходу и не придумаю сценария, какие это могут быть данные и почему они должны быть именно в сессии.
Сначала надо определиться — нужна ли блокировка сессии. Это зависит от того, какие данные хранятся в сессии и как они используются.
В своё время я для своего проекта пришёл к выводу, что от блокировки можно отказаться.
Далее пользовал встроенные механизмы memcache(d), но в итоге остановился на использовании очень простых собственных хэндлеров. Получив при этом прозрачный для меня механизм сессии, вместо «чёрного ящика». Это оказалось плюсом, т.к. проект был нагружен (более миллиона pageview в сутки).
Вот код:
function my_session_open($save_path, $session_name) {
return true;
}
function my_session_read($id) {
$GLOBALS['session_read_return'] = Cache_Proxy::get($id);
return $GLOBALS['session_read_return'];
}
function my_session_write($id, $data) {
if ($GLOBALS['session_read_return'] == $data) return true; // Если в пределах этого запроса данные не менялись - не записываем их обратно
return Cache_Proxy::set($id, $data, 0, 36000);
}
function my_session_destroy($id) {
Cache_Proxy::delete($id);
return true;
}
function my_session_gc($maxlifetime) {
return true;
}
function my_session_close() {
return true;
}
session_set_save_handler('my_session_open', 'my_session_close', 'my_session_read', 'my_session_write', 'my_session_destroy', 'my_session_gc');
register_shutdown_function('session_write_close');
В качестве кэша используется APC (apc_fetch и apc_store). Работает очень быстро при любых нагрузках. Сбором мусора занимается АРС.
PS: если бы завтра нужно было писать новый проект с нуля, я бы вообще не стал бы использовать такой механизм как сессии. По сути вся «сессия» — это уникальная кука на клиенте + данные на стороне сервера, однозначно связанные со значением этой куки. Так зачем всё усложнять и вносить в систему такой чёрный ящик, как стандартные сессии? (прошу воспринимать это не как совет, а как личное мнение, которое вполне может быть ошибочным)
«Изменение хандлеров сессии не поможет.»
Прекрасно помогает изменение или переписывание хэндлеров на те, которые используют неблокируемые ресурсы для хранения сессионных данных.
Имеет также смысл подумать, а нужна ли вам именно PHP-сессия, и для чего? Есть и другие инструменты.
Если человек ввел email, который зарегистрирован в системе, и неправильный пароль от него, надо к красненькому тексту «Вы ввели неверный пароль», добавлять ссылку не «Восстановить пароль», а «Отправить письмо для восстановления пароля на xxx@mail.ru».
А после 2-ой неудачной попытки — отправлять это письмо автоматически.
Совсем не так. Будь у нас 100% открытие писем — мы бы не заморачивались с конверсией и оптимизацией. Фактически подтверждают свой email менее 85%, а добавление большой синей ссылки «Открыть почту» (для мэйлру, яндекса и гмейла), вопреки ожиданиям, не изменило этот процент.
Напишите «Войти через Gmail» и будет вам счастье.
Померяли конверсию.
Она не изменилась.
Вообще.
Спасибо за внимание.
Кстати, это еще на удивление редкая и хорошая ситуация. Обычно присылают в понедельник после обеда, с мотивацией «Клиент должен был увидеть это еще утром, сейчас сидит жутко злой и звонит каждые 5 минут». Тогда не то что на выходных — приходится буквально ночью работать.
К таким вещам — только иммунитет. Сами заварили кашу — пусть сами и выкручиваются.
> программисты не могут мне дать чёткую эстимацию по задачам!
С этим ничего не поделаешь, но это немного другое. Если программист оценил задачу, т.е. у него было достаточно времени на её выполнение по его же собственной оценке — тогда в некоторых случаях (много чего завязано уже на дату предполагаемого запуска) можно и сверхурочно попросить поработать.
Из-за плохо сделавших свою работу менеджеров (плохое планирование), вынуждены тратить свои выходные разработчики, как правило не виновные во внезапном появлении «срочных» задач.
Как только ко мне пришло это понимание, я выработал иммунитет к «срочным» и особенно «сверхсрочным» задачам, и спокойно отдыхаю в свои выходные.
Зачем?
У нас используется похожая схема, и в ней есть nginx.
В нашей схеме наличие сгенерированного файла проверяет сначала nginx и если нужная картинка уже есть — отдаёт её своими силами.
Если же файл не найден — происходит передача запроса Апачу, а далее всё по похожей схеме как в данной статье
А хранить в сессии какие-то другие данные? Сходу и не придумаю сценария, какие это могут быть данные и почему они должны быть именно в сессии.
В своё время я для своего проекта пришёл к выводу, что от блокировки можно отказаться.
Далее пользовал встроенные механизмы memcache(d), но в итоге остановился на использовании очень простых собственных хэндлеров. Получив при этом прозрачный для меня механизм сессии, вместо «чёрного ящика». Это оказалось плюсом, т.к. проект был нагружен (более миллиона pageview в сутки).
Вот код:
В качестве кэша используется APC (apc_fetch и apc_store). Работает очень быстро при любых нагрузках. Сбором мусора занимается АРС.
PS: если бы завтра нужно было писать новый проект с нуля, я бы вообще не стал бы использовать такой механизм как сессии. По сути вся «сессия» — это уникальная кука на клиенте + данные на стороне сервера, однозначно связанные со значением этой куки. Так зачем всё усложнять и вносить в систему такой чёрный ящик, как стандартные сессии? (прошу воспринимать это не как совет, а как личное мнение, которое вполне может быть ошибочным)
Прекрасно помогает изменение или переписывание хэндлеров на те, которые используют неблокируемые ресурсы для хранения сессионных данных.
Имеет также смысл подумать, а нужна ли вам именно PHP-сессия, и для чего? Есть и другие инструменты.