Сегодня мыслил про капчу...
Абстрактный конь в вакууме...
Предположим у нас есть некоторый код, генерирующий картинку.
Рассмотрим варианты сохранения валидного результата:
1) После генерации валидного результата, пишем его в сессию и генерируем картинку на его же основе.
2) После генерации валидного результата, пишем его в БД и генерируем картинку на его же основе.
Если я забыл еще какие-то классические варианты - дополните.
Так вот, мысль о абстрактных конях возникла не с проста, а в виду желания уменьшить нагрузку на сервер.
Напомню как происходит весь этот процесс:
1) Вываливается хтмл-страница.
2) Браузер найдя ссылку на картинку капчи ломится за ней, капча генерируется всегда, валидная сессия или запись в БД обновляется/добавляется всегда.
3) На следующей необходимой странице вся эта кухня валидируется, либо тащим из БД, либо из сессии.
Попытаемся заапгрейдить:
1) На известной странице генерируется валидный результат и пишется в сессию.
2) Вываливается хтмл-страница.
3) Браузер найдя ссылку на картинку капчи ломится за ней, предоставляя сессию с валидным результатом.
4) Картинка капчи генерируется только в том случае, если сессия имеется в наличии и не устарела, (на усмотрение разработчика).
5) На следующей необходимой странице вся эта кухня валидируется из сессии.
Так, что у нас тут получается?
Мы выносим всякие там рандомизаторы и сессии из скрипта капчи.
Все генерации и проверки идут только в контексте бизнес-логики.
Капча не рисуется лишний/каждый раз и не жрет ресурсы машинки.
Ну и естественно капча занимается только тем, чем ей положено - только лишь отрисовывает картинку.
Х.з., может я и прописные истины тут щас напечатал, пусть даже и так - главное прозрел, главное сам...
|