Если юзер нажал Cancel download

Written by elwood

В сервлете будет выброшено исключение org.apache.catalina.connector.ClientAbortException (при вызове ServletOutputStream.write(); )
Чтобы в лог не капали мусорные сообщения об этих исключениях:

} catch (org.apache.catalina.connector.ClientAbortException e) {
    // do nothing - client has cancelled the download
}

Либа, содержащая класс ClientAbortException – либо томкатовская catalina, либо джейбоссовский jbossweb.jar (в который эмбеддится каталина).
Судя по факу http://www.jboss.org/jbossweb/faq.html, в jbossweb используется tomcat версии 6.0.13+
Так как нам в этом случае совпадение версий некритично, мы можем использовать 6.0.13 (или jbossweb.jar в качестве compile-time-lib, если используется ant).

Мейвеновские координаты каталины:

<!-- JBoss Web is based on Tomcat 6.0.13 -->
<!-- this dependency is only to catch org.apache.catalina.connector.ClientAbortException in file download servlets -->
<dependency>
    <groupId>org.apache.tomcat</groupId>
    <artifactId>catalina</artifactId>
    <version>6.0.13</version>
    <scope>provided</scope>
</dependency>

Эмуляция плохого канала связи

Written by elwood

За отладкой программы, которая постоянно посылает и принимает сообщения по GPRS с сервера, почувствовал необходимость в имитации плохого соединения, погуглил инструменты и нашел следующее:

1. SoftPerfect Connection Emulator – платная (100 баксов за standard edition), встала на мою Win7 x64 без проблем, позволяет выбрать сетевой интерфейс и задать ему скорость и различные побочные эффекты (% потерь пакетов, дубликаты пакетов, reordering). К сожалению, в триальной версии можно юзать сессии не более 30 секунд, потом сетевой интерфейс начинает работать как обычно и надо заново включать эмуляцию. 30 секунд – это слишком мало, поэтому стал искать дальше.

2. Wipfw – портированный с FreeBSD стандартный инструмент, позволяет делать почти все что и SoftPerfect, но, к сожалению, работает пока только на Windows XP или Windows Server 2003. Ну, мне большего и не надо, взял соседнюю свободную тачку, поставил туда wipfw и запустил серверное приложение. Все сработало наура, сначала подключился в обычном режиме, начал передавать данные и на второй машине включил 100% потери пакетов. Некоторые сообщения успели “отправиться” перед тем, как приложение поняло, что соединение не функционирует. И следующие сообщения уже были сохранены в локальном хранилище для отправки, когда соединение восстановится. Естественно, первые сообщения, “отправленные” на сервер – потерялись.

Минигайд по wipfw. Программа ставится как служба (service) сетевого интерфейса (ее видно, если зайти в свойства соединения), и висит постоянно.
А для манипуляции правилами нужно запускать ipfw.exe.

Вот так можно посмотреть список всех правил: ipfw.exe show
А так удалить все правила (программа спросит подтверждения): ipfw.exe flush
Полный запрет на прием IP-пакетов с хоста 172.28.1.4: ipfw.exe add deny ip from 172.28.1.4 to any
Потеря 30% пакетов: ipfw.exe add prob 0.3 deny ip from 172.28.1.4 to any

Настройка SSL для томката. Взгляд с 1000 метров.

Written by elwood

На неделе столкнулся с задачей сформировать подписанный сертификат SSL и установить его в JBoss AS. До этого там работал самоподписанный сертификат, сформировать который достаточно просто с использованием утилитки keytool. Эта программа входит в набор, поставляемый вместе с JDK, поэтому имеется у всех джаверов. Так как до меня достаточно долго доходило, что, собственно, требуется, попробую описать вкратце, что к чему.

Итак, нам нужно настроить SSL на томкате (в моем случае был JBoss, но там внутри все равно томкат, так что разницы нет). Что значит настроить SSL ? Это означает, что томкат должен уметь принимать входящие подключения на некий порт (обычно 443) по протоколу HTTPS. Для этого необходимо настроить коннектор, он настраивается в server.xml (в томкате его проще найти, в JBoss он упрятан глубоко, в один из деплоеров – WebDeployer). Чтобы настроить коннектор, нужно указать ему порт, некоторые дополнительные настройки, а также keystore + keystore password – собственно самая важная часть этого конфига.

Что же такое keystore ? Это просто файл, хранящий связки ключей и сертификаты. Файл может быть запаролен (поэтому для доступа к нему в конфиге прописывается keystore password). Для работы SSL необходима пара ключей (public + private) плюс сертификат, который доказывает подлинность этой пары ключей. Сертификат по сути представляет собой public-ключ, подписанный (см. цифровая подпись) одним из доверенных центров сертификации. Схема примерно такая – клиент при создании защищенного соединения смотрит сертификат, и либо доверяет ему (если он подписан авторитетным центром), либо выводит сообщение о недоверенном сертификате (что мы часто наблюдаем в браузерах). К слову, сертификат может быть подписан с помощью другого подписанного сертификата, таким образом, могут образовываться цепочки сертификатов, и в этом случае доверенным сертификатом должен быть хотя бы ROOT-сертификат. Ну и собственно эта пара ключей и цепочка сертификатов хранятся в keystore.

Есть 2 пути сделать себе keystore. Первый – самый простой – создать пару ключей и ей же самой подписать публичный ключ, получив сертификат. Это и есть самоподписанный сертификат. Его проблема в том, что нет причин доверять такому сертификату, поскольку любому человеку под силу создать такой сертификат. Такие сертификаты при использовании их на сайтах как раз и приводят к большим красным сообщениям о том, что де-сайт плохой и надо с него валить.

Второй – получение пары ключей с сертификатом, подписанным доверенным центром. Тут чуть сложнее, сначала опять же нужно сгенерить себе пару ключей и засунуть ее в свежесозданный keystore. Потом – создать запрос на получение сертификата (CSR-файл), он делается одной командой из созданного keystore. Дальше надо отправить этот файл в центр сертификации и дождаться выдачи сертификата. Центр сертификации выдаст нам файл, содержащий искомый сертификат и (при необходимости) цепочку доверенных сертификатов. Всё это добро мы импортируем в исходный keystore и.. вуаля, мы имеем настоящий подписанный доверенным центром SSL сертификат!

Пара технических деталей. Keystore представляет собой по сути сериализованную мультимапу alias -> objects[], где алиасом является некая строка, а object – либо keyentry, либо trusted cert entry. Названия говорят сами за себя. Следствие идентификации по алиасу – вы должны делать импорт полученных из центра сертификатов на тот же алиас, на который вы создавали keypair.

Парочка ссылок на толковое описание по шагам, что нужно делать (с командами для keytool):
Генерация ключей и создание запроса на получение сертификата
Инсталляция полученного сертификата в tomcat