Например, у нас на производстве, экспедиторы, работающие посменно, находили ошибки предшественника и хотели бы их исправить, но период неумолимо закрывался в конце каждой смены и не было никакой возможности внести изменения. Опущу детальное описание регламента внесения изменений - здесь оно не важно.
После нескольких очень ранних утренних звонков, когда приходилось включать комп, подключаться к удаленной базе и что-то править, именно тогда и пришло в голову это решение.
Допустим, сегодня 11 февраля 2011 года. Пользователю необходимо внести изменения за предыдущую дату - 10.02.11. Он связывается с администратором, объясняет причину, слышит в ответ «39 21 94 10», вводит эту цифирь в обработку "Изменение рабочей даты" и получает доступ.
Теперь о том - откуда взялись эти цифры и почему система приняла их как корректный код. Всё очень просто - структура кода доступа такова:
(две любые цифры=39)
(31-ТекущееЧисло=21)
(опять две любые цифры=94)
(12-ТекущийМесяц=10)
Программа легко вычислила, какой код должен ввести пользователь, сверила с тем что он реально ввел и в соответствии с результатом проверки приняла решение - пускать или не пускать.
На любой другой день код доступа будет другой, так что повторно им воспользоваться не удастся. За счет использования «двух любых цифр» алгоритм формирования кода становится менее предсказуемым.
Вариаций на эту тему может быть сколь угодно много - например вместо «двух любых цифр» или вместо вычисляемых чисел использовать (Текущий час в Австралии), можно учитывать чет/нечет даты или количество дней до пятницы, использовать контрольную сумму чисел и т.д. и т.п.
Общая рекомендация по алгоритму формирования кода - он должен легко генерироваться администратором базы в уме и вместе с тем, алгоритм составления не должен быть очевидным. И не забудьте защитить программу проверки кода паролем или обфускацией.
