技术领域
[0001] 本
发明涉及计算机应用技术领域，特别涉及一种支持多种浏览器与本地应用程序进行通信的方法。
背景技术
[0002] 目前主流的浏览器有Microsoft Internet Explorer、Google Chrome、MozillaFirefox、360安全浏览器等。现有存在的支持浏览器调用本地应用程序的方案有以下几种：
[0003] (1)Microsoft的ActiveX/COM
[0004] Microsoft Internet Explorer使用Microsoft的ActiveX/COM，但是目前win10采用的默认浏览器是Edge，不再是Microsoft Internet Explorer，当前的本地应用程序
中间件是无法在Edge中使用的。随着业务发展，越来越多用户期望可以同时兼容Chrome、FireFox、Edge等浏览器。
[0005] (2)Netscape NPAPI
插件[0006] 旧版本的Chrome和FireFox使用Netscape NPAPI，运行在NPAPI插件中的代码拥有当前用户的全部权限，不能利用Google Chrome的沙箱技术和其他安全防护技术。鉴于NPAPI可能引入的
风险，从2014年1月开始，Chrome Stable版本将阻止网页安装NPAPI插件，并且从Chrome 45版本开始已经正式弃用NPAPI插件。
[0007] (3)浏览器扩展
[0008] 新版本的Chrome使用Google Chrome扩展和Native Messaging来使浏览器和应用程序进行交互，但是谷歌的
网站通常很难
访问，安装扩展也不甚方便。
[0009] 微软的Edge，也是通过浏览器扩展的方式与本地应用程序进行交互。
[0010] (4)自定义协议
[0011] 自定义协议，类似于mailto http https，主流浏览器都支持，只需要在注册表中添加相应内容即可，如在页面启动迅雷下载器。但是这种方案只是在浏览器中启动本地应用程序，而无法达到使浏览器和应用程序进行交互的目的。
[0012]
现有技术方案存在以下问题：1)需要针对不同的浏览器进行研究，并采用针对性的开发，开发和维护的工作量都比较大。2)通常这些开发技术都是各个浏览器私有的，如果选用不当，可能以后会不再支持的风险，比如以前的NPAPI。3)即使自定义协议可以满足各个浏览器调用本地应用程序但是无法满足浏览器和本地应用程序交互的需求。
[0013] 现有技术中各个浏览器的机制不同，需要采用不同的方式来实现，因此，在当前环境下，需要有更便利的方式来支持各种浏览器调用本地应用程序，并且满足浏览器和本地应用程序进行交互的需求。
发明内容
[0014] 本发明的目的在于克服现有技术的缺点与不足，提供一种支持多种浏览器与本地应用程序进行通信的方法，利用自定义URL使浏览器启动本地应用程序，可以满足浏览器和本地应用程序交互的需求，兼容各种浏览器，克服了各主流浏览器
内核不同、开发技术不一，以至于不兼容给用户带来的使用不便的问题。
[0015] 本发明的目的通过以下的技术方案实现：一种支持多种浏览器与本地应用程序进行通信的方法，包括以下步骤：
[0016] 步骤1：浏览器向应用系统
服务器发出
请求；
[0017] 步骤2：应用系统服务器组织请求内容，向辅助服务器请求服务；
[0018] 步骤3：辅助服务器认证应用系统服务器，认证成功之后产生请求id并根据请求内容构造一个自定义URL，返回给应用系统服务器；
[0019] 步骤4：应用系统服务器将自定义URL返回给浏览器；
[0020] 步骤5：浏览器进一步组织自定义URL，通过自定义URL链接，在网页中调用本地应用程序或者显示二维码图片，当显示为二维码图片时则由移动端的应用程序进行扫描；
[0021] 步骤6：本地应用程序解析URL参数，将操作结果提交给辅助服务器；
[0022] 步骤7：在步骤5之后，浏览器向应用系统服务器查询结果；
[0023] 步骤8：应用系统服务器向辅助服务器查询结果；
[0024] 步骤9：辅助服务器向应用系统服务器返回步骤6的结果；
[0025] 步骤10：应用系统服务器将结果返回到浏览器。
[0026] 优选的，浏览器向应用系统服务器发出的请求可以是证书登录、表单签名、证书绑定等。
[0027] 优选的，步骤2中应用系统服务器组织请求内容，通过post方式向辅助服务器请求服务。
[0028] 优选的，步骤3中
应用服务器和辅助服务器之间采用应用账号和认证码的认证方式。
[0029] 优选的，步骤6中本地应用程序解析URL参数，通过post方式将操作结果提交给辅助服务器。
[0030] 优选的，步骤7中浏览器开启长轮询或者长连接通过post方式向应用系统服务器查询结果。
[0031] 优选的，步骤8中辅助服务器向应用系统服务器返回步骤6的结果，应用系统服务器对辅助服务器返回的操作结果进行验证，验证操作结果是否有效；验证有效之后将操作结果返回给浏览器。
[0032] 优选的，本方法采取单向证书SSL的方式。
[0033] 本发明与现有技术相比，具有如下优点和有益效果：
[0034] 1、本发明利用自定义URL使浏览器启动本地应用程序，可以满足浏览器和本地应用程序交互的需求，兼容各种浏览器，克服了各主流浏览器内核不同、开发技术不一，以至于不兼容给用户的使用带来很大的不便的问题，同时PC端和手机端都可以使用。
[0035] 2、本发明采取单向证书SSL的方式，服务器之间使用应用账号和认证码的方式进行认证，在安全上保证了数据的保密传输。
附图说明
[0037] 图2是实施例2使用数字证书登录的流程示例图。
具体实施方式
[0038] 下面结合实施例及附图对本发明作进一步详细的描述，但本发明的实施方式不限于此。
[0039] 实施例1
[0040] 一种支持多种浏览器与本地应用程序进行通信的方法，本方法涉及到浏览器、应用系统服务器、辅助服务器、本地应用程序。通过应用系统服务器和辅助服务器，浏览器可以实现与本地应用程序的间接交互。其中为了使本地应用程序能够更好的实现与浏览器进行交互，也便于应用开发的集成，使用了辅助服务器，辅助服务器主要根据应用请求的内容来构造URL，以及将本地应用程序的运行结果传送给应用系统服务器。
[0041] 具体流程如下：
[0042] 步骤1：浏览器向应用系统服务器发出请求(登陆，表单签名等)。
[0043] 步骤2：应用系统服务器组织请求内容，通过post方式向辅助服务器请求服务。
[0044] 步骤3：辅助服务器通过应用账号和密码认证应用系统服务器，认证成功之后产生requestid值即请求id，这个请求id是唯一的，并根据请求内容构造一个自定义URL(URL Scheme)，返回给应用系统服务器。
[0045] 步骤4：应用系统服务器将自定义的URL返回给浏览器。
[0046] 步骤5：浏览器进一步组织URL，通过自定义URL链接，在网页中调用本地应用程序，或者显示二维码图片，当显示为二维码图片时则由移动端的应用程序进行扫描。
[0047] 步骤6：本地应用程序解析URL参数，由于URL链接的格式是标准的，在使用过程中，只需要对其中的参数进行解析，根据参数进行相应的操作，通过post方式将操作结果提交给辅助服务器。
[0048] 步骤7：在步骤5之后，浏览器开启长轮询或者长连接通过post方式向应用系统服务器查询结果。
[0049] 步骤8：应用系统服务器向辅助服务器查询结果。
[0050] 步骤9：辅助服务器向应用系统服务器返回步骤6的结果。
[0051] 步骤10：应用系统服务器将结果返回到浏览器。
[0052] 实施例2
[0053] 一种支持多种浏览器与本地应用程序进行通信的方法，以数字证书登录为例的操作流程包括：
[0054] 步骤1：浏览器向应用系统服务器提交登录请求；
[0055] 步骤2：应用系统服务器产生随机数random；
[0056] 步骤3：应用系统服务器根据应用账号和密码，向辅助服务器发送签名请求。
[0057] 步骤4：辅助服务器成功认证应用系统服务器后返回响应结果，即自定义的URL：NetcaCryptoSvr://？requestId＝requestId&submitUrl＝url
[0058] 其中url scheme为NetcaCryptoSvr://，
[0059] 传递的参数为：requestId＝requestId&submitUrl＝url。
[0060] 其中submitUrl为本地应用程序向辅助服务器提交结果的url。
[0061] 步骤5：返回浏览器页面。
[0062] 步骤6：浏览器进一步组织自定义URL，则最终拼接自定义url为：
[0063] NetcaCryptoSvr://？requstId＝requsId&submitUrl＝url&function＝certLogin¶m＝param
[0064] 如果通知类型是二维码，则此时内容格式和url scheme一样，只不过转换为二维码的PNG格式图片。
[0065] 步骤7：浏览器通过自定义URL链接跳转到本地应用程序或者显示二维码图片。
[0066] 步骤8：浏览器开启长轮询或者长连接。
[0067] 步骤9：本地应用程序开始解析自定义url参数进行签名操作。
[0068] 步骤10：本地应用程序将签名结果提交给辅助服务器。
[0069] 步骤11：应用系统服务器向辅助服务器查询签名结果。
[0070] 步骤12：辅助服务器返回签名结果。
[0071] 步骤13：应用系统服务器对12返回的签名结果进行验证。
[0072] 步骤14：应用系统服务器根据签名结果验证数字证书。
[0073] 步骤15：返回成功页面或失败页面。
[0074] 本方法不仅可以兼容各种浏览器，使浏览器可以调用本地应用程序，还可以实现浏览器和本地应用程序的交互。为了使浏览器和本地应用程序达到交互，先让浏览器向应用系统服务器发请求服务，然后应用系统服务器根据请求的内容返回响应的结果，应用系统服务器将返回的结果给浏览器，浏览器进一步组织自定义url，浏览器可以根据通知类型选择操作，当通知类型为url scheme时直接url scheme跳转到本地应用程序，当是二维码时显示二维码图片，由移动端应用程序执行扫码。PC端或者移动端应用程序分析url参数，根据参数进行相应的操作，并把操作结果提交给辅助服务器。应用系统服务器向辅助服务器查询操作结果，并对辅助服务器返回的操作结果进行验证，验证操作结果是否有效；验证之后将操作结果返回给浏览器，进而浏览器和本地应用程序实现间接的交互。
[0075] 为了保证数据的保密传输，本方法采用单向证书认证SSL，并且应用服务器和辅助服务器之间采用应用账号和认证码的认证方式。
[0076] 本方法不仅PC端而且手机端也可以使用，在一些特有场景下：证书登录，表单签名，证书绑定等常见业务流程尤其适用。如果通知类型为URL Scheme，则适用于手机端B/S、C/S应用，手机端签名等，PC端的B/S、C/S应用，PC端签名等；如果通知类型为二维码，则适用于PC端的B/S、C/S应用，手机端签名等。
[0077] 上述实施例为本发明较佳的实施方式，但本发明的实施方式并不受上述实施例的限制，其他的任何未背离本发明的精神实质与原理下所作的改变、修饰、替代、组合、简化，均应为等效的置换方式，都包含在本发明的保护范围之内。
