实名认证功能
前面的文章中我们实现了后台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请求时会报错。
跨域请求：
跨域不允许；
本页面
function abc(data){
alert(data);
}
<script src="hello.js"></script>
hello.js：内容: abc("你好");
效果，弹出你好；
1、跨域两种解决办法；
1）、jsonp；代表发起跨域请求；
利用浏览器对于script,img,a href没有跨域限制；
服务器不能反回json数据；
反回一个类似方法调用的格式；将交给浏览器的数据作为这个方法的参数；abc(json)；
浏览器端正巧有这个方法名的方法；每次一返回相当于是对这个方法的调用；方法的参数就是数据；
1.1）、$.get(url?callback=?)
callback=? jquery随机搞一个方法名 作为回调函数
服务器；获取到callback的值，把数据夹里面写出去
abc(json)；
服务还是返回json；
2）、服务器端进行跨域设置；浏览器发数据的数据的时候加上请求头说我要跨域；
服务器加上响应头，说谁能跨域？（告诉浏览器不要限制哪些地址ajax请求）；
1+1=2
SpringMVC使用配置
这样就可以开启跨域请求啦！ 是不是很简单！！！！
后台manager系统的实名认证人工审核
上边我们实现了前台用户web系统的实名认证功能，可是用户光提交了实名认证申请是不够的，这个功能还没有结束。剩下的事情就是需要啊后台管理人员进行人工审核，检查用户提交的信息是否正确或真实，通过审核的用户才算是真正的实名认证成功。
那我们就来实现一下这个后台manager系统中后台管理人员使用的实名认证人工审核功能吧！
首先，人工审核就是manager系统的业务审核-实名认证这个功能，点击实名认证就会跳转到审核认证页面，页面中的审核列表会显示出所有实名认证流程当中执行到人工审核这一任务的流程，后台管理人家只需要对某一流程进行审核就行啦!
先配置数据库中的t_permission表中的实名认证链接，和图标。让在点击实名认证的时候跳转到审核列表页面。
在controller中处理这个请求audi/auth/list，先查询所有正在执行中，流程名字叫做人工审核的流程，再根据所有的流程实例id取得开启流程的用户信息和用户相应的资质信息。将这些信息放在隐藏域中并跳转到审核列表页面。
添加审核列表页面，这个页面也很简单只需要拿之前其他的页面修改一下就好了。
在页面中将我们保存到隐藏域的所有信息显示到审核列表中。
用户的资质信息我们采用弹出模态框的形式显示。
点击列表中某一审核信息中的点击预览按钮，将该条审核信息中用户的资质信息显示在模态框中。
如果后台的管理人员查看该用户的信息与相关资质信息都符合要求，那么就可以通过审核啦！点击列表中某一用户相关的申请中的审核按钮，将该用户的id作为参数发送审核通过请求。成功返回后重新显示审核列表页面（刷新页面）。
在controller中添加审核通过的处理方法。先将activiti数据库中所有运行流程中执行到人工审核任务的流程信息全部取出来，再根据用户id查找到的流程实例id，找到某一具体的流程信息。然后执行完成这个流程信息中的人工审核任务。
就这么简单的完成啦。
好了，我们测试一下吧！
登录用户，点击业务审核-实名认证，跳转到认证列表页面。
点击预览按钮，查看用户的资质信息（因为我们的资质信息是上传到的前台用户的接口服务器中scw-restapi，我们查看用户的资质信息时也是向scw-restapi发送图片请求，所以可不要忘了启动scw-restapi服务呦！！！）。
检查过资质信息后点击审核按钮，通过人工审核，实名认证成功。
通过后我们再来看这个认证列表页面，此时认证列表中已经没有需要人工审核的任务啦！
ok！到这里，有关什么认证的前台、后台功能都完成啦！
