Некоторые
провайдеры поддерживают такую фичу, как
добавление денег на счет с карточки.
Карточка - просто красивая бумажка с
паролем. Смысл фичи в том, что клиент не
обязан ходить в офис провайдера, чтобы
заплатить за диалап, а может сходить в киоск,
купить карточку, зайти на провайдерский
сайт, ввести там свой логин и пароль с
карточки, и таким образом перечислить
некоторую сумму к себе на счет.
Внутренности системы: в базе данных
провайдера хранятся пароли карточек и
количество денег на счету абонента. Не
важно, как работает веб-интерфейс всего
этого дела, кончается все одинаково:
браузер подает финальный запрос серверу, а
тот - к базе данных. Запрос состоит из двух
частей: "зачислить деньги на счет" и
"аннулировать карточку".
Алгоритм работы сервера:
1. Проверить, что карточка существует и не
использована. Если неудачно - сообщить
клиенту об ошибке и завершить обработку.
2. Добавить деньги на счет клиента.
3. Пометить карточку как "использованную".
Далее по причине отсутствия у разработчиков
биллинговых систем мультизадачного
мышления может возникнуть такая фича.
Абонент подает подряд несколько запросов
на использование карточки. Рассмотрим два
потока событий, A и B.
A0. Сервер принимает запрос на использование
карточки.
B0. Сервер принимает запрос на использование
карточки.
A1. Проверить, что карточка существует и не
использована.
-ПРОВЕРКА УДАЧНА. ИДЕМ ДАЛЬШЕ-
B1. Проверить, что карточка существует и не
использована.
-ПРОВЕРКА УДАЧНА. ИДЕМ ДАЛЬШЕ-
A2. Добавить деньги на счет клиента.
B2. Добавить деньги на счет клиента.
A3. Пометить карточку как использованную
B3. Пометить карточку как использованную
(тут может возникнуть ошибка, но ее вряд ли
кто-то обрабатывает).
Обратите внимание, шаг "добавить деньги
на счет клиента" был УСПЕШНО выполнен
дважды. Понятно, что можно послать гораздо
больше запросов. Все зависит от того,
насколько быстро вы можете их подавать (скорость
канала) и насколько медленно
обрабатывается шаги 2 и 3.
Единственное решение - блокировка БД от
шага 1 и до шага 3. Тогда второй поток не
сможет обратиться для проверки валидности
карточки до тех пор, пока она не будет
анулированна. Создатели биллинговой
системы должны предусмотреть возможность
одновременного прихождения двух запросов
за время обработки и вызвать блокировку.
Если БД быстрая или разработчики пытались
защититься через веб-интерфейс (что вообще
говоря в данном случае неэффективно), то
есть хорошие шансы, что использовать
описанную фичу удастся, т.к. разработчики
скорее всего не предусмотрели эту ситуацию.
Есть информация,
что тема обсуждалась и раньше. Но разговор с
несколькими людьми, занимающимися
биллинговыми системами, показал, что она
все еще может быть актуальна.
