與reCAPTCHA的Spring集成

有時我們只需要CAPTCHA ，這是一個可悲的事實。今天，我們將學習如何與reCAPTCHA集成。因為主題本身并不是特別有趣和高級，所以我們將通過使用Spring Integration處理低級細節來過度設計（？）。 Google決定使用reCAPTCHA的決定取決于兩個因素：（1）這是一種適度良好的CAPTCHA實施方案，具有體面的圖像，并內置了對視力障礙者的支持；（2）外包CAPTCHA可使我們在服務器端保持無狀態。更不用說我們在圖書數字化方面有所幫助。

第二個原因實際上很重要。通常，您必須在服務器端生成CAPTCHA，并將預期結果存儲在例如用戶會話中。當響應返回時，您比較預期的并輸入了CAPTCHA解決方案。有時我們不想在服務器端存儲任何狀態，更不用說實現驗證碼并不是特別有意義的任務。因此，擁有現成的和可以接受的東西真是太好了。

完整的源代碼一如既往地可用，我們從一個簡單的Spring MVC Web應用程序開始，沒有任何驗證碼。 reCAPTCHA是免費的，但需要注冊，因此第一步是在我們的示例項目中唱歌并生成您的公鑰/私鑰和填寫的app.properties配置文件。

要在表單上顯示reCAPTCHA并將其包括在表單中，只需添加JavaScript庫：

<div id="recaptcha"> </div>
...
<script src="http://www.google.com/recaptcha/api/js/recaptcha_ajax.js"></script>

并將reCAPTCHA小部件放置在您喜歡的任何位置：

Recaptcha.create("${recaptcha_public_key}","recaptcha",{theme: "white",lang : 'en'}
);

官方文檔非常簡潔，描述性強，因此我不會深入探討這一細節。當您在<form/>包含此小部件時，當用戶提交時，您將收到兩個額外的字段： recaptcha_response_field和recaptcha_challenge_field 。第一個是用戶鍵入的實際文本，第二個是每個請求生成的隱藏令牌。 reCAPTCHA服務器可能會將它用作會話密鑰，但是我們不在乎，我們要做的就是將此字段進一步傳遞給reCAPTCHA服務器。我將使用HttpClient 4對外部服務器執行HTTP請求，并在Scala中執行一些巧妙的模式匹配來解析響應：

trait ReCaptchaVerifier {def validate(reCaptchaRequest: ReCaptchaSecured): Boolean}@Service
class HttpClientReCaptchaVerifier @Autowired()(httpClient: HttpClient,servletRequest: HttpServletRequest,@Value("${recaptcha_url}") recaptchaUrl: String,@Value("${recaptcha_private_key}") recaptchaPrivateKey: String) extends ReCaptchaVerifier {def validate(reCaptchaRequest: ReCaptchaSecured): Boolean = {val post = new HttpPost(recaptchaUrl)post.setEntity(new UrlEncodedFormEntity(List(new BasicNameValuePair("privatekey", recaptchaPrivateKey),new BasicNameValuePair("remoteip", servletRequest.getRemoteAddr),new BasicNameValuePair("challenge", reCaptchaRequest.recaptchaChallenge),new BasicNameValuePair("response", reCaptchaRequest.recaptchaResponse))))val response = httpClient.execute(post)isReCaptchaSuccess(response.getEntity.getContent)}private def isReCaptchaSuccess(response: InputStream) = {val responseLines = Option(response) map {Source.fromInputStream(_).getLines().toList} getOrElse NilresponseLines match {case "true" :: _ => truecase "false" :: "incorrect-captcha-sol" :: _=> falsecase "false" :: msg :: _ => throw new ReCaptchaException(msg)case resp => throw new ReCaptchaException("Unrecognized response: " + resp.toList)}}}class ReCaptchaException(msg: String) extends RuntimeException(msg)

唯一缺少的部分是ReCaptchaSecured特性，它封裝了前面提到的兩個reCAPTCHA字段。為了使用reCAPTCHA保護任何Web表單，我只是在擴展此模型：

trait ReCaptchaSecured {@BeanProperty var recaptchaChallenge = ""@BeanProperty var recaptchaResponse = ""
}class NewComment extends ReCaptchaSecured {@BeanProperty var name = ""@BeanProperty var contents = ""
}

整個CommentsController.scala并不相關。但是結果是！

這樣就可以了，但是顯然不是很壯觀。您如何用Spring Integration替換低級HttpClient調用？ ReCaptchaVerifier接口（特征）保持不變，因此不必更改客戶端代碼。但是我們將HttpClientReCaptchaVerifier重構為兩個單獨的，較小的，相對高級的抽象類：

@Service
class ReCaptchaFormToHttpRequest @Autowired() (servletRequest: HttpServletRequest, @Value("${recaptcha_private_key}") recaptchaPrivateKey: String) {def transform(form: ReCaptchaSecured) = Map("privatekey" -> recaptchaPrivateKey,"remoteip" -> servletRequest.getRemoteAddr,"challenge" -> form.recaptchaChallenge,"response" -> form.recaptchaResponse).asJava}@Service
class ReCaptchaServerResponseToResult {def transform(response: String) = {val responseLines = response.split('\n').toListresponseLines match {case "true" :: _ => truecase "false" :: "incorrect-captcha-sol" :: _=> falsecase "false" :: msg :: _ => throw new ReCaptchaException(msg)case resp => throw new ReCaptchaException("Unrecognized response: " + resp.toList)}}}

請注意，我們不再需要實現ReCaptchaVerifier ，Spring Integration將為我們做到這一點。我們只需要告訴我們框架應該如何使用上面提取的構建塊。我想我還沒有描述Spring Integration是什么以及它是如何工作的。簡而言之，它是企業集成模式的非常純凈的實現（有人可能將其稱為ESB）。消息流是使用XML描述的，可以嵌入到標準Spring XML配置中：

<?xml version="1.0" encoding="UTF-8"?>
<beans:beans xmlns:beans="http://www.springframework.org/schema/beans"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xmlns="http://www.springframework.org/schema/integration"xmlns:http="http://www.springframework.org/schema/integration/http"xsi:schemaLocation="http://www.springframework.org/schema/integrationhttp://www.springframework.org/schema/integration/spring-integration.xsdhttp://www.springframework.org/schema/beanshttp://www.springframework.org/schema/beans/spring-beans.xsdhttp://www.springframework.org/schema/integration/httphttp://www.springframework.org/schema/integration/http/spring-integration-http.xsd"><!-- configuration here -->    </beans:beans>

在我們的案例中，我們將描述從HttpClientReCaptchaVerifier Java接口/ Scala特征到reCAPTCHA服務器再返回的消息流。在必須將ReCaptchaSecured對象轉換為HTTP請求并將HTTP響應轉換為有意義的結果的方式上，該方法從接口透明返回。

<gateway id="ReCaptchaVerifier" service-interface="com.blogspot.nurkiewicz.recaptcha.ReCaptchaVerifier" default-request-channel="reCaptchaSecuredForm"/><channel id="reCaptchaSecuredForm" datatype="com.blogspot.nurkiewicz.web.ReCaptchaSecured"/><transformer input-channel="reCaptchaSecuredForm" output-channel="reCaptchaGoogleServerRequest" ref="reCaptchaFormToHttpRequest"/><channel id="reCaptchaGoogleServerRequest" datatype="java.util.Map"/><http:outbound-gatewayrequest-channel="reCaptchaGoogleServerRequest"reply-channel="reCaptchaGoogleServerResponse"url="${recaptcha_url}"http-method="POST"extract-request-payload="true"expected-response-type="java.lang.String"/><channel id="reCaptchaGoogleServerResponse" datatype="java.lang.String"/><transformer input-channel="reCaptchaGoogleServerResponse" ref="reCaptchaServerResponseToResult"/>

盡管有大量的XML，但是整個消息流還是非常簡單的。首先我們定義網關，它是Java接口和Spring Integration消息流之間的橋梁。 ReCaptchaVerifier.validate()的參數稍后變成一條消息，該消息發送到reCaptchaSecuredForm channel 。 ReCaptchaSecured對象從該通道傳遞到ReCaptchaFormToHttpRequest 轉換器。轉換器的用途是從ReCaptchaSecured對象到Java映射的兩次轉換，代表一組鍵值對。稍后，此映射（通過reCaptchaGoogleServerRequest通道）傳遞到http:outbound-gateway 。該組件的職責是將先前創建的地圖轉換為HTTP請求并將其發送到指定的地址。

響應返回時，將其發送到reCaptchaGoogleServerResponse通道。 ReCaptchaServerResponseToResult轉換器將采取行動，將HTTP響應轉換為業務結果（布爾值）。最終，轉換器結果被路由回網關。默認情況下，所有操作都是同步發生的，因此我們仍然可以使用簡單的Java接口進行reCAPTCHA驗證。

信不信由你，這一切正常。我們不再使用HttpClient （猜測一切都比HttpClient 4 API更好……），而不是一個“巨大”的類，我們有一組較小的，集中的，易于測試的類。該框架處理接線和底層細節。精彩？

建筑師的夢想還是開發商的噩夢？

讓我通過引用以上介紹的結論來總結我們的努力：在架構利益與開發有效性之間取得平衡 。 Spring Integration能夠從各種異構源（如JMS，關系數據庫甚至FTP）接收數據，以多種方式聚合，拆分，解析和過濾消息，最后使用最奇特的協議進一步發送消息。手工編寫所有代碼是一項非常繁瑣且容易出錯的任務。另一方面，有時我們只是不需要所有的幻想，而弄臟我們的手（例如，通過執行手動HTTP請求并解析響應）則更加簡單易懂。在盲目地將整個體系結構基于非常高級的抽象或基于手工編碼的低級過程之前，請考慮一下后果和平衡。沒有解決方案可以解決所有問題。您發現哪個版本的reCAPTCHA集成更好??？

參考資料： 使用…與reCAPTCHA集成... Java社區博客上的JCG合作伙伴 Tomasz Nurkiewicz的Spring Integration 。