Аутентификация с помощью CustomAuthenticator, кого-то пожалуйста, просветите меня

Question

Хорошо после экспериментирования немного я узнал, что смола называет мой метод аутентификации AbstractAuthenticator, который принимает объект HttpDigestCredentials вместо DigestCredentials (до сих пор не знаю, когда каждый из них), проблема в том, что HttpDigestCredentials не имеет метода getDigest(), вместо этого он имеет метод getResponse(), который не возвращает хеш или, по крайней мере, не сопоставимый.

После создания моего собственного хэша [[user: realmassword] [nonce] [method: uri]] хэш очень отличается, на самом деле я думаю, что getResponse() не возвращает дайджест, но, возможно, ответ сервера на браузер ?.

В любом случае, это мой отладки журнала:

USER:user:PASSWORD:password:REALM:resin:METHOD:GET:URI/appe/appe.html:NONCE:HsJzN+j+GQD:CNONCE:b1ad4fa1ba857cac88c202e64528bc0c:CLIENTDIGEST:[B@5dcd8bf7:SERVERDIGEST:I4DkRCh21YG2Mk14iTe+hg== 

, как вы можете увидеть, как предполагаемый клиент нонс очень сильно отличается от сервера генерируется нонса, на самом деле клиент нонс не похож на MD5 хэш вообще.

Пожалуйста, кто-то это делает раньше? есть ли что-то в HttpDigestCredentials? Я знаю, что дайджест едва используется.

Пожалуйста, я знаю о SSL, но у меня пока нет сертификата SSL, поэтому не говорите мне «Почему бы вам не использовать SSL». ;)

Update:

Не уверен, что если было правильно сделать, но, как я прочитал, прежде чем смола использует формат base64 для хэшей, поэтому я использовал Apache Commons-кодек-1,6 использовать метод encodeBase64String(), и теперь хэши выглядят одинаково, но они не совпадают.

Я попытался как passwordDigest.getPasswordDigest(a1+':'+nonce+':'+a2); passwordDigest.getPasswordDigest(a1+':'+nonce+':'+ncount+':'+cnonce+':'+qop+':'+a2);

и ни один из них не дает такой же хэш, как один из HttpDigestCredentials.

Answer 1

Хорошо, я, наконец, сделал это. Странный предмет. Да, только два взгляда?

Во-первых, аутентификация дайджеста использует пользователя, пароль, царство, nonce, client_nonce, nonce_count, метод, qop и uri. В основном он использует полную спецификацию дайджеста. Поэтому, чтобы вычислить хеш, нужно рассчитать его со всеми свистками. Это всего лишь вопрос вызова метода get для каждой из переменных из HttpDigestCredentials, за исключением пользователя и пароля. Пользователь будет в форме Принципала и пароль, который вы должны искать самостоятельно в своей БД (в моем случае база данных DB4O).

Затем вы должны создать объект PasswordDigest, который позаботится о генерации хэша с методом getPasswordDigest(), но сначала нужно установить формат hex с помощью пароляDigestObject.setFormat ("hex").

Существует один для HA1 getPasswordDigest (пользователь, пароль, область), и есть еще один метод getPasswordDigest(), который принимает только одну строку, и можно использовать его для генерации остальных хэшей, как HA2, так и предыдущих хешировал HA1 конечным хешем, конечно же, с nonce_count client_nonce и qop, конечно, каждый из которых разделялся точкой с запятой.

Тогда это сложная часть, хотя смола работает с кодировкой base64 для переваривания, когда вы вызываете метод getResponse() из HttpDigestCredentials, он возвращает массив байтов (что странно), поэтому для сравнения с вашим хешем, что я использовал метод Hex.encodeHexString() из org.apache.commons.codec.binary.Hex и передал возвращаемое значение HttpCredentialsDigest getResponse(), и это даст хорошую шестую строку для сравнения.

Я делал это наоборот, я использовал хэш Base64 из PasswordDigest и преобразовал хэш HttpDigestCredentials в Base64, и результирующая строка никогда не была прежней.