У меня обычно весь последний год заявки подписываются без проблем, но изредка возникала описанная в теме ситуация - обычно повторная отправка заявки через час-другой решала проблему. Но последнее время ситуация воспроизводится с 100% вероятностью. Например, 15 августа заявка отправилась успешно, а за последние 4 дня - ни разу не получалось подписать распоряжение.
Я посмотрел в wireshark: при отправке заявки успешно устанавливается https-соединение на 193.28.44.147 - сервер raiffeisen, судя по whois:
route: 193.28.44.0/24
descr: RAIFFEISENBANK AUSTRIA, MOSCOW
origin: AS31174
mnt-by: ROSNIIROS-MNT
mnt-routes: RAIFFEISENBANK-MNT
source: RIPE # FilteredПроходит ssl-handshake, апплет отправляет запрос. Ровно через 90 секунд (±200ms) от сервера приходит какой-то (зашифрованный, поэтому в wireshark сложно его увидеть) ответ. В этот же момент апплет выдаёт сообщение
ошибка при отправке сообщения на сервер.
Тут я уже и хотел отправить это сообщение на форум, но вспомнил ещё кое-что.
Когда я обратился в службу поддержки, ничего внятного мне сказать не могли, но саппорт упомянул что-то про DNS и я полез в wireshark снова.
Когда я хожу по сайту connect.raiffeisen.ru, запросы уходят на 193.28.44.148, что, в целом, звучит разумно
connect.raiffeisen.ru. 2743 IN CNAME connect.gss.raiffeisen.ru.
connect.gss.raiffeisen.ru. 13 IN A 193.28.44.148
148.44.28.193.in-addr.arpa. 3600 IN PTR connect.raiffeisen.ru.
Обратим внимание, что апплет стучится на 193.28.44.147, а не на 148, что TTL connect.gss.raiffeisen.ru всего 20 секунд, что перед обращением к ...44.147 апплет не ходит в DNS - т.е. либо этот адрес закэширован где-то, либо он жестко зашит в самом апплете.
Если сходить в них браузером по https, то создается впечатление (возможно, ошибочное), что на этих серверах один и тот же код - во всяком случае прямой заход в ...147 позволяет авторизоваться и получить свои счета.
Что интересно, база данных пользовательских сессий на ...147 и ...148 различная - залогиненность на одном сайте не приводит к залогиненности на другом. Этот факт я проверил, прописав жестко IP-адрес для connect.raiffeisen.ru в /etc/hosts
Особенно этот факт умиляет в паре с TTL = 20 секунд и длинной сессии в 30 минут. Видимо, это особенности реализации балансировки и/или failover. Судя по регулярным ошибкам
Your session is expired. Please log in again, которые я вижу - не самой удачной реализации.
Но база данных заявок общая - отправив заявку с ...147, убрав запись из /etc/hosts, перезапустив браузер и перелогинившись я заявку увидал на своём месте.
Хорошо, заявку я наконец-то отправил, но хочется избежать пляски с /etc/hosts в дальнейшем. Запустив
IcedTea Web Control Panel я нашёл в кэше только два jar-ника. После того как я почистил кэш "rm -rf ~/.icedtea/cache", апплет вообще перестал загружаться в firefox с ошибкой "Start: applet not initialized."
Попытка загрузить его в chromium тоже не увенчалась успехом - в этом случае вообще никакой диагностики не было.
Ещё раз почистил кэш icedtea, перезапустил firefox и попробовал провести операцию второй раз - на этот раз всё прошло удачно, впрочем, апплет загрузился на английском языке
Итого: похоже, приходится чистить кэш, т.к. где-то в кишках апплета залипает старый IP.
Что доставляет отдельно - на странице загрузки апплета в апплет передаётся параметр keystore.path - строка к хранилищу ключей на моей локальной файловой системе (/home/darkk/blah-blah-blah). Не думал, что это значение хранится на серверах райффайзена.