實名認證功能
前面的文章中我們實現了後臺manager系統中的流程管理功能，並且將實名認證的流程上傳到了服務器並完成部署。不過，僅僅是長傳和部署當然不是我們的目的啦！我們上傳這個實名認證流程時爲了可以讓前臺的廣大用戶可以使用這個流程，怎麼才能使用這個功能呢？那當然是每個用戶都需要的實名認證功能啦！
好，我們就來實現實名認證這個功能吧！首先實名認證這個功能是在前臺系統的會員中心當中。
點擊未實名認證就會跳轉到實名認證的賬戶類型選擇頁面。
在賬戶類型選擇頁面中選中我們的類型後點擊認證申請進行認證。
這這大體就是實名認證的幾個步驟，在填寫完驗證碼之後點擊申請完成按鈕，後臺會校驗我們輸入的驗證碼信息，如果校驗成功，會提示我們success實名認證成功。如果校驗失敗，會根據我們規定的流程重新執行某一個任務，直到整個流程當中所有的任務全部完成爲止。
好，實名認證中的幾個步驟搞清楚啦！那麼我們創建的流程應該何時啓動呢？還記得我們創建的實名認證流程中的幾個任務嗎？當流程啓動之後，有三個任務需要執行，分別是發送驗證碼給用戶、提交驗證碼開始驗證、人工審覈三個任務。第一個任務發送驗證碼給用戶是使用向用戶的郵箱發送郵件的方式發送臨時生成的驗證碼，而用戶的郵箱地址是由外面傳進來的。上面的步驟3郵箱確認中正是我們填寫自己郵箱地址的地方，所以我們的流程啓動的時機，應該是在步驟3完成之後，也就是填寫完自己的郵箱地址，點擊下一步的時候啓動實名認證的流程（再將我們在前幾個步驟收集到的有用信息傳遞到流程中）。因爲流程中的第一個任務是發送郵件（自動的，由activiti自己調用發送郵件的api，不需要我們操心）。那麼第二個任務是在什麼時候執行的呢？第二個任務是提交驗證碼開始驗證，這個任務也需要外邊傳入的數據（驗證碼）。這個驗證碼應該與我們前邊第一個任務發送郵件中的驗證碼保存一致（驗證通過），否則驗證失敗。這個任務應該在步驟4申請確認之後執行，也就是在確定用戶輸入的驗證碼後，點擊申請完成按鈕後開始執行這個任務。如果用戶填寫的驗證碼與我們發送的驗證碼一致，流程就會進入下一個任務（人工審覈）。此時距跟用戶沒什麼關係啦，因爲人工審覈是需要後臺管理員去審覈的，用戶只能查看審覈結果（審覈通過或未通過）。
首先是用戶類型選擇。選擇完後會發送相關類型認證頁面的請求。
在controller中處理這個請求，並跳轉頁面。
爲了減少頁面的跳轉，只是讓頁面進行局部刷新，所以這個authpage.jsp頁面是個空頁面，內容需要單獨發送ajax請求去獲取。
它默認會發送步驟1的ajax請求來刷新頁面。
在controller中處理並跳轉到步驟1的apply.jsp。
在apply.jsp中填寫用戶信息後點擊下一步按鈕，將收集到的用戶信息作爲參數發送跳轉的步驟2的ajax請求。
在controller中將用戶提交過來的信息保存到數據庫中（通過遠程調用restapi的方式）。
保存成功後再根據用戶類型獲取用戶所需要上傳的所有資源，然後跳轉到步驟2的apply-1.jsp頁面。
在apply-1.jsp頁面中以遍歷的方式顯示用戶需要上傳的所有文件類型。
每一個需要上傳的資料類型在選中某一資料後，還可以進行預覽。所有需要的資料都選擇好之後，點擊下一步發送去往步驟3apply-2.jsp頁面的請求並提交我們要上傳的所有資料。
在controller中跳轉到appl-2頁面。
可是我們的所有資料的上傳操作在哪裏呢？我們所有資料的上傳操作不應該在scw-portal中進行上傳操作。雖然前面步驟1當中的用戶信息是通過scw-portal中的controller中專來發送遠程請求到scw-restapi進行保存，但這種方式卻不適合我們用來上傳文件。因爲我們上傳的文件要比普通的用戶信息大很多，這樣纔去中轉的方式非常佔用網絡資源。所以我們採取不中轉，從頁面端直接向scw-restapi端上傳文件，這樣就省去了中間環節。可是這種從頁面端向另一個服務器地址上傳文件的ajax請求，在瀏覽器中是不被允許的，需要我們進行跨域設置。具體的設置方法下邊在細說。
在遠程服務scw-restapi的controller中處理上傳文件的請求，保存上傳過來的資質文件並更新數據庫信息。
在步驟3的apply-2.jsp頁面中填寫我們自己的郵箱地址用於接收驗證碼，然後點擊下一步發送驗證碼到郵箱併發送去步驟4appl-3.jsp頁面的請求。
在controller中處理這個想郵箱地址發送驗證碼的請求，將發送郵件的請求轉發到遠程服務scw-restapi中。
如果發送郵件成功了，就跳轉到步驟4的appl-3.jsp頁面。
在遠程服務scw-restapi的controller中先保存用戶與郵箱的信息，然後發送郵件。
在service中根據用戶id來保存用戶的郵箱地址。
在service中發送驗證碼到郵箱，如何發郵件呢？這就需要我們之前上傳上來的activiti的流程啦。我們創建的實名認證流程中第一個任務就是發送郵件任務，並且這個發郵件的任務是activiti自動發送的，不需要我們做任何操作。我們要做到就是找到我們之前已經部署到服務器中的實名認證流程，並開啓這個流程，那麼第一個任務就會自動執行啦。因爲我們流程中的任務會需要使用從外部傳入的數據，所以開啓流程的同時還要出入需要的數據。爲了方便我們之後的使用，我們會新創建一張t_member_ticket數據庫表，專門用於存儲用戶id與開啓的流程實例id的對應關係。這樣我就可以容易的查到某個用戶開啓了哪些流程。
不過這裏有個地方需要注意，雖然發送郵件任務是activiti自動完成的，但是如果我們使用自己搭建的郵箱地址向某個郵箱地址發送郵件時，我們還需要啓動我們自己的郵件服務程序（比如apache-james）。
執行到這個步驟的時候，如果郵件發送成功，我們應該已經跳轉到apply-3.jsp頁面啦！這一步需要我們輸入我們接收到的郵件中的驗證碼來進行確實。如果我們輸入的驗證碼也郵件中的驗證碼一致，那麼我們的流程就可以執行下一個任務啦！我們的流程中一共有三個任務，第一個發送郵件的任務activiti已經幫我們自動執行完啦！接下來的第二個任務提交驗證碼開始驗證正式我們在這個步驟應該做的工作。
在apply-3.jsp頁面中輸入我們接受到的驗證碼，發送驗證請求進行驗證。
在scw-portal的controller中處理校驗請求，訪問遠程服務進行校驗，如果校驗成功就跳轉到success.jsp頁面。
在遠程服務scw-restapi中的controller中處理校驗請求。在controller中如何校驗驗證碼呢？校驗驗證碼這個過程我們已經創建在實名認證的流程當中啦！已經不需要我們自己校驗啦！我們只需要執行實名認證流程當中的提交驗證碼開始認證這個任務就可以啦！當然在執行這個任務的時候還需要傳入必要的參數，還記得那些參數麼？我們創建這個任務的時候需要外邊傳入的兩個參數usercode和code（用戶輸入的驗證碼和向郵件中發送的驗證碼）。執行了這個任務後如何知道這個任務執行成功了並且成功進入到流程中的下一個任務了呢？也很簡單，執行完任務後再次取得當前任務的名稱，用這個名稱與執行任務之前的任務名稱進行比較，如果相同，說明執行任務失敗啦，流程又返回到了最近一次執行的任務。如果不同，說明任務執行成功，流程進入到了下一個任務。
如果執行到了下一個任務，也就是實名認證流程中的最後一個任務---人工審覈。那麼實名認證這個功能對於我們用戶來說就算是完成了，因爲剩下的最後一個任務是由我們後臺管理人員進行的人工審覈工作。如果審覈通過，用戶的實名認證就徹底完成啦！如果審覈不通過，那麼用戶就要重新開啓一個實名認證的流程，重新認證。
現在我們來執行這個實名認證測試一下吧！
測試之前有兩個地方需要注意！
1，因爲之前在後臺manager系統中我們已經將實名認證這個流程上傳服務器，並且部署過啦!我們想要測試這個流程只需要找到這個流程並且執行就可以啦！查找部署好的流程當然是根據id或者名字查找啦！（可以去數據庫中查看，免得執行的時候找不到流程）。
2，因爲實名認證這個流程中有個發送郵件的任務，而我們發送郵件時使用的是自己搭建的郵件服務器發送的，所以應該先開啓我們自己搭建的郵件服務器，免得發送郵件任務執行不成功。
好，都準備好了的話那就開始測試吧！
先開啓前臺用戶web端專有服務和前臺所有客戶端的api接口服務。
使用前臺用戶賬號登錄網站並進入會員中心頁面。
點擊未實名認證按鈕進入實名認證-賬戶類型選擇頁面，選擇賬戶類型。選完後點擊認證申請。開始認證。
在實名認證-申請頁面的基本信息中填寫個人信息，然後點擊下一步。
在實名認證-申請頁面的資質文件上傳頁面中上傳相應的文件，然後點擊下一步。
在實名認證-申請中的郵箱地址頁面中填寫正確的郵箱地址，然後點擊下一步按鈕，發送郵件。
此時查看eclipse的控制檯可以看見我們在代碼中打印的log信息，顯示發送郵件成功，並且也成功的接收到了郵件。
將郵件中的驗證碼添寫到實名認證-申請的申請確認頁面中，然後點擊申請完成按鈕。等到校驗驗證碼的結果。
如果我們填寫的驗證碼與郵件中的驗證碼一致，就校驗成功並跳轉到success頁面，要我們等待管理員的人工審覈，到這裏實名認證的前臺用戶操作完成。
我們也可以到activiti的數據庫中查看相應的流程信息。
可以看到我們剛剛執行的流程實例信息。
也可以看這個流程都執行了哪些任務，有沒有結束，目前執行到了那個任務。
甚至在流程執行的過程中使用的具體參數都可以看到。
是不是很簡單！
ok，實名認證的前臺用戶認證申請功能完成啦！！！
ajax發送跨域請求
接下來我們說說上邊提到的使用ajax發送跨域請求。
由於瀏覽器的限制，是不允許一個地址下服務中使用ajax向另一個地址的服務器發送請求的。比如我們的前臺web服務scw-portal項目中使用ajax向scw-restapi發送上傳文件請求。由於scw-portal使用的端口號是8081，而scw-restapi使用的8082端口。所以發送ajax請求時會報錯。
<script src="hello.js"></script>
利用瀏覽器對於script,img,a href沒有跨域限制；
反回一個類似方法調用的格式；將交給瀏覽器的數據作爲這個方法的參數；abc(json)；
瀏覽器端正巧有這個方法名的方法；每次一返回相當於是對這個方法的調用；方法的參數就是數據；
callback=? jquery隨機搞一個方法名 作爲回調函數
2）、服務器端進行跨域設置；瀏覽器發數據的數據的時候加上請求頭說我要跨域；
服務器加上響應頭，說誰能跨域？（告訴瀏覽器不要限制哪些地址ajax請求）；
這樣就可以開啓跨域請求啦！ 是不是很簡單！！！！
後臺manager系統的實名認證人工審覈
上邊我們實現了前臺用戶web系統的實名認證功能，可是用戶光提交了實名認證申請是不夠的，這個功能還沒有結束。剩下的事情就是需要啊後臺管理人員進行人工審覈，檢查用戶提交的信息是否正確或真實，通過審覈的用戶纔算是真正的實名認證成功。
那我們就來實現一下這個後臺manager系統中後臺管理人員使用的實名認證人工審覈功能吧！
首先，人工審覈就是manager系統的業務審覈-實名認證這個功能，點擊實名認證就會跳轉到審覈認證頁面，頁面中的審覈列表會顯示出所有實名認證流程當中執行到人工審覈這一任務的流程，後臺管理人家只需要對某一流程進行審覈就行啦!
先配置數據庫中的t_permission表中的實名認證鏈接，和圖標。讓在點擊實名認證的時候跳轉到審覈列表頁面。
在controller中處理這個請求audi/auth/list，先查詢所有正在執行中，流程名字叫做人工審覈的流程，再根據所有的流程實例id取得開啓流程的用戶信息和用戶相應的資質信息。將這些信息放在隱藏域中並跳轉到審覈列表頁面。
添加審覈列表頁面，這個頁面也很簡單只需要拿之前其他的頁面修改一下就好了。
在頁面中將我們保存到隱藏域的所有信息顯示到審覈列表中。
用戶的資質信息我們採用彈出模態框的形式顯示。
點擊列表中某一審覈信息中的點擊預覽按鈕，將該條審覈信息中用戶的資質信息顯示在模態框中。
如果後臺的管理人員查看該用戶的信息與相關資質信息都符合要求，那麼就可以通過審覈啦！點擊列表中某一用戶相關的申請中的審覈按鈕，將該用戶的id作爲參數發送審覈通過請求。成功返回後重新顯示審覈列表頁面（刷新頁面）。
在controller中添加審覈通過的處理方法。先將activiti數據庫中所有運行流程中執行到人工審覈任務的流程信息全部取出來，再根據用戶id查找到的流程實例id，找到某一具體的流程信息。然後執行完成這個流程信息中的人工審覈任務。
就這麼簡單的完成啦。
好了，我們測試一下吧！
登錄用戶，點擊業務審覈-實名認證，跳轉到認證列表頁面。
點擊預覽按鈕，查看用戶的資質信息（因爲我們的資質信息是上傳到的前臺用戶的接口服務器中scw-restapi，我們查看用戶的資質信息時也是向scw-restapi發送圖片請求，所以可不要忘了啓動scw-restapi服務呦！！！）。
檢查過資質信息後點擊審覈按鈕，通過人工審覈，實名認證成功。
通過後我們再來看這個認證列表頁面，此時認證列表中已經沒有需要人工審覈的任務啦！
ok！到這裏，有關什麼認證的前臺、後臺功能都完成啦！
在最後附上代碼以供需要時查看：